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