public key size

I am not going to be picky, let's do 256 bit aes keys like before, and
if it's not the worst computation in the world, could we try 4096 pub
keys to see how it goes, and if it's not really practical or scalable,
we'll stick with 2048. I'm a picky crypto guy and like to follow
parameters correctly, even though this one is debatable, I do believe in
protecting those session keys with the equivalent strength pub key
crypto.

Lance

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of auto97841-revL73yDgGBWk0Htik3J/[email protected]
Sent: Wednesday, August 06, 2003 10:59 PM
To: [email protected]
Subject: [iip-dev] 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