public key size

'lo hez, nop, et al

Two comments:

- First comment, wrt: Why 2048/128 vs 4096/256?  
Simple answer: Computational resources required.  I2P is a very crypto
heavy system, and this end to end encryption is only a small part of
that load.  Remember, in addition to encrypting and decrypting messages
destined to the local machine, the router will be encrypting and decrypting
connections to other routers, exchanging keys, wrapping and unwrapping
free route mixed messages, and verifying signatures, along with analyzing
the performance of various aspects of the network to optimally integrate
itself further.

The client library's built in end to end encryption should perform sufficiently
for all application models - not only email over I2P, but for things
like streaming data - as all messages sent through the API will include
this encryption.  Applications that require greater security than what
the client library provides transparently should have additional encryption
(trading off cpu usage for security).  One can't use 8192/512 bit encryption
to do streaming video on a 386, for example.

Also note that the keys for the 128 bit encryption is rotated periodically
- whenever a message is sent ElG'ed instead of just session tagged.

Again, we don't need transparent military grade encryption in the API
to allow transparent military grade encryption to be used by applications
that need it.  The reason I'm not recommending going even further down
towards 1024/64 is that the public key is rotated significantly less
often (a paranoid person should feel safe not rotating it for weeks,
while joe sixpack should feel safe not rotating it for months or years).
 Its my understanding that 1024bit keys do not meet those security requirements,
 though 2048 does.  Am I wrong and we instead need to use 4096 bit public
keys?

- Second comment, wrt: AES attacks
If we don't feel AES is secure, at least for the next 3-5 years, we shouldn't
use it.  However, what I've read and what I've heard is that there may
be a theoretical attack which may be able to build a cryptographic attack
which may succeed in theory, though it may not be implementable practically,
 and even if all of those "may be" phrases turned to definite "is a"
phrases, it would likely be 10 years out.

I'd like to stick with AES, at least for now.  I'm sure if this is a
significant problem, it will come up during peer review and we can substitute
algorithms for the end to end payload encryption then.

(and, btw, the 32 bytes are used for the AES *pre*-IV, not the IV (IV
= SHA256(32byteTag)[0:15] ), and they're used for consistency with the
size of the session tag, which is 32 bytes so as to minimize the chance
of collision with an ElG'ed message's first 32 bytes)

anyway, thats my take on things.  its almost 9am so I'll prolly be asleep
shortly...

-jrandom



Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427