For both scenarios, this method encrypts the AES area using the given key, iv
and making sure the resulting data is at least as long as the paddedSize and
also mod 16 bytes.
scenario 1:
Begin with 222 bytes, ElG encrypted, containing:
- 32 byte SessionKey
- 32 byte pre-IV for the AES
- 158 bytes of random padding
Then encrypt with AES using that session key and the first 16 bytes of the SHA256 of the pre-IV:
- 2 byte integer specifying the # of session tags
- that many 32 byte session tags
- 4 byte integer specifying data.length
- SHA256 of data
- 1 byte flag that, if == 1, is followed by a new SessionKey
- data
- random bytes, padding the total size to greater than paddedSize with a mod 16 = 0
Contains the private key which matches the EndPointPublicKey which, in turn,
is published on the LeaseSet and used to encrypt messages to the router to
which a Destination is currently connected.
When the given peer is performing well enough that we want to keep detailed
stats on them again, call this to set up the info we dropped during shrinkProfile.
Periodically search through all leases to find expired ones, failing those
keys and firing up a new search for each (in case we want it later, might as
well preemptively fetch it)
Search for a particular key iteratively until we either find a value, we run
out of peers, or the bucket the key belongs in has sufficient values in it.
Go through the kbuckets and generate random keys for routers in buckets not
yet full, attempting to keep a pool of keys we can explore with (at least one
per bucket)
Extract the payload carried by an I2P repliable datagram (previously
loaded with the loadI2PDatagram() method), without verifying the
datagram signature.