Re: crypto stuff

Hi jrandom,

Wednesday, October 1, 2003, 5:37:43 PM, you wrote:

j> ok, we've got two(+) things on the crypto deck here:
j> 1) ElG+AES session management
j> 2) streaming AES for TCP
j> +) PRNG

j> 1) ElG+AES session management

j> As I said in the meeting, ElG+AES works fine when blocks/messages aren't
j> lost or severely out of order, but if:
j> 1.1) the first block is lost, we're screwed as the recipient doesn't
j> get the session key
j> 1.2) another block with session tags is lost, K following blocks are
j> lost as the session tags they use will not be recognized
j> Point 1.1 requires us to keep using ElG until we know for sure that its
j> been received, and point 1.2 requires us to tap dance to either know
j> for sure that all tags sent are usable (by resending the tags in further
j> blocks until we get one of them acked) or go probabalistic and hope that
j> out of the K blocks sent with tags, at least one makes it through

j> This affects both the end to end encryption (in the SDK) and the garlic
j> encryption (in the router), as they both use ElG+AES.  Rather than be
j> hasty and implement what I think will be sufficient, I'm being cautious
j> and saying all blocks will include the ElG until the Right Way is figured
j> out and implemented.  A performance hit, yes, but its better than losing
j> entire sessions intermittently.

j> 2) Streaming AES for TCP

j> We agreed on using bytes 32-47 from the DH exchange for the IV during
j> the meeting, but one question I have is whether we should go with CBC
j> (requiring padding since not all reads/writes are 16 bytes), or should
j> we go CFB  (allowing us to read/write any byte we're given)?  Pros/cons
j> anyone?

j> If not, I'm going to go ahead and do CBC+PKCS#5 (using the last byte
j> = # padding bytes, with all of the padding bytes equal to that #, e.g.
j> 0x42 0x43 0x44 0x45 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a
j> 0x0a 0x0a)

j> +) PRNG

j> We're still using the default java.security.SecureRandom (wrapped via
j> net.invisiblenet.i2p.util.RandomSource), and it'd be nice to get rid
j> of that sometime... its startup overhead is a bitch (hoses the JVM for
j> ~5 seconds on my p4 1.7).  I've looked at freenet's Yarrow, and we could
j> use it, though it seems to include some assumptions and dependencies
j> that aren't in place for us.  Any PRNG experts have any suggestions?
j>  This is low priority, as we're functional as is, but it'd be nice to
j> get rid of that 5 second bootup lag.

j> Thats it for now.
j> -jr



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

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

j> Promote security and make money with the Hushmail Affiliate Program:
j> https://www.hushmail.com/about.php?subloc=affiliate&l=427
j> _______________________________________________
j> iip-dev mailing list
j> [email protected]
j> http://lists.invisiblenet.net/mailman/listinfo/iip-dev

Quickly on the yarrow, I believe it is to be the most reliable and
secure PRNG out there to date, although, looking at Seth Hardy's
erandom, it looks attractive but isn't a proven standard at this time,
but is Provably secure. I believe when Seth gets on tonight, it would
also be advised to discuss this with him, he has an in depth recent
knowledge of PRNG, and I believe he would agree that Yarrow is
definitely sufficient.

I need to look over the other stuff when I have a bit of bandwidth,
I'll get back to you shortly.

-- 
Best regards,
 Lance                            mailto:[email protected]
InvisibleNet
www.invisiblenet.net

_______________________________________________
iip-dev mailing list
[email protected]
http://lists.invisiblenet.net/mailman/listinfo/iip-dev