crypto stuff
"jrandom" <auto97841-revL73yDgGBWk0Htik3J/[email protected]> Wed, 1 Oct 2003 17:37:43 -0700
| Newsgroups | gmane.comp.security.invisiblenet.iip.devel |
|---|---|
| Message-ID | <[email protected]> |
ok, we've got two(+) things on the crypto deck here: 1) ElG+AES session management 2) streaming AES for TCP +) PRNG 1) ElG+AES session management As I said in the meeting, ElG+AES works fine when blocks/messages aren't lost or severely out of order, but if: 1.1) the first block is lost, we're screwed as the recipient doesn't get the session key 1.2) another block with session tags is lost, K following blocks are lost as the session tags they use will not be recognized Point 1.1 requires us to keep using ElG until we know for sure that its been received, and point 1.2 requires us to tap dance to either know for sure that all tags sent are usable (by resending the tags in further blocks until we get one of them acked) or go probabalistic and hope that out of the K blocks sent with tags, at least one makes it through This affects both the end to end encryption (in the SDK) and the garlic encryption (in the router), as they both use ElG+AES. Rather than be hasty and implement what I think will be sufficient, I'm being cautious and saying all blocks will include the ElG until the Right Way is figured out and implemented. A performance hit, yes, but its better than losing entire sessions intermittently. 2) Streaming AES for TCP We agreed on using bytes 32-47 from the DH exchange for the IV during the meeting, but one question I have is whether we should go with CBC (requiring padding since not all reads/writes are 16 bytes), or should we go CFB (allowing us to read/write any byte we're given)? Pros/cons anyone? If not, I'm going to go ahead and do CBC+PKCS#5 (using the last byte = # padding bytes, with all of the padding bytes equal to that #, e.g. 0x42 0x43 0x44 0x45 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a 0x0a) +) PRNG We're still using the default java.security.SecureRandom (wrapped via net.invisiblenet.i2p.util.RandomSource), and it'd be nice to get rid of that sometime... its startup overhead is a bitch (hoses the JVM for ~5 seconds on my p4 1.7). I've looked at freenet's Yarrow, and we could use it, though it seems to include some assumptions and dependencies that aren't in place for us. Any PRNG experts have any suggestions? This is low priority, as we're functional as is, but it'd be nice to get rid of that 5 second bootup lag. Thats it for now. -jr 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 _______________________________________________ iip-dev mailing list [email protected] http://lists.invisiblenet.net/mailman/listinfo/iip-dev