Commit Graph

26 Commits

Author SHA1 Message Date
jrandom
756a4e3995 added a section for congestion control describing what I hope to implement. what
/actually/ gets implemented will be documented further once its, er, implemented
2005-04-04 17:21:30 +00:00
jrandom
17f044e6cd if using numACKs, use a 2 byte value (to handle higher transfer rates) 2005-03-30 00:20:07 +00:00
jrandom
be9bdbfe0f * simplify the MAC construct with a single HMAC (the other setup was an oracle anyway)
* split out the encryption and MAC keys
2005-03-27 22:08:16 +00:00
jrandom
5c2a57f95a minor cleanup 2005-03-26 09:22:17 +00:00
jrandom
9cd8cc692e added replay prevention blurb, minor cleanup 2005-03-26 09:19:42 +00:00
jrandom
0626f714c6 speling (thanks cervantes) 2005-03-26 06:23:57 +00:00
jrandom
21842291e9 *cough* 2005-03-26 05:56:06 +00:00
jrandom
d461c295f6 first draft of secure semireliable UDP protocol 2005-03-26 05:47:40 +00:00
jrandom
8b9ee4dfd7 updated to reflect what was implemented 2005-02-17 00:48:18 +00:00
jrandom
a33de09ae6 * implemented fragmentation
* added more inbound tests
* made the tunnel preprocessing header more clear and included better fragmentation support
(still left: tests for outbound tunnel processing, structures and jobs to integrate with the router,
remove that full SHA256 from each and every I2NPMessage or put a smaller one at the
transport layer, and all the rest of the tunnel pooling/building stuff)
2005-01-25 05:46:22 +00:00
jrandom
998f03ba68 killed the loops and the PRNGs by having the tunnel participants themselves specify what
tunnel ID they listen on and make sure the previous peer doesn't change over time.  The
worst that a hostile peer could do is create a multiplicative work factor - they send N
messages, causing N*#hops in the loop of bandwidth usage.  This is identical to the hostile
peer simply building a pair of tunnels and sending N messages through them.
also added some discussion about the tradeoffs and variations wrt fixed size tunnel messages.
2005-01-19 23:13:10 +00:00
jrandom
f3b0e0cfc7 we want to use E on the preIV, not HMAC - must be invertible (duh, thanks Connelly)
adjusted preIV size accordingly, and definitely use a delivered layerIVKey
2005-01-19 06:24:25 +00:00
jrandom
cd939d3379 speling mistaces 2005-01-18 16:21:12 +00:00
jrandom
29e5aeff5c include the preIV in the verification hash 2005-01-18 16:01:55 +00:00
jrandom
0e5cf81fca updates with new alternative crypto, including Connelly's suggestions for the IV 2005-01-18 15:55:17 +00:00
jrandom
ccb1f491c7 use the first 16 bytes of the SHA256 for the columns & verification block, rather than all 32 bytes.
(AES won't let us go smaller.  oh well)
2005-01-16 06:07:06 +00:00
jrandom
6b6a9490f6 include blurb explaining tunnelIDs and replay prevention (thanks Connelly!) 2005-01-16 00:08:14 +00:00
jrandom
c48875a6fb cbc, nimwit 2005-01-15 06:43:35 +00:00
jrandom
75a18debcb forgot to update the processing xor 2005-01-15 03:53:13 +00:00
jrandom
1a15d3bb55 filled in the tunnel building alternatives, throttling techniques, and mixing (meta)details 2005-01-15 00:06:40 +00:00
jrandom
ffdcae47e3 add some whitening to the IV as it goes down the path 2005-01-14 22:43:43 +00:00
jrandom
9c364a64e3 more arm waiving wrt the tunnel building 2005-01-13 00:57:36 +00:00
jrandom
b34306205c lets just get some visual versioning clues 2005-01-12 19:22:40 +00:00
jrandom
77f778dbf9 Updated the crypto so that peer0 is the gateway (meaning max hop length is 8, not 9).
This prevents the first peer after the gateway from looking at the encrypted data received
and seeing "hey, none of the checksum blocks match the payload, they must be the gateway".
2005-01-12 19:09:00 +00:00
jrandom
8fa8d7739f work in progress, but i want it in cvs so i dont lose it again 2005-01-09 23:01:34 +00:00
cvs_import
77bd69c5e5 beginning of branch i2p.i2p.i2p 2004-04-08 04:41:54 +00:00