On Sun, May 06, 2001 at 11:24:15AM +0100, Adam Langley wrote: > On Sun, May 06, 2001 at 04:26:12AM -0400, Tavin Cole wrote: > > > > The document is encrypted and interleaved with the progressive hash > > > control bytes. Its length must be a power of 2 _prior_ to the addition > > > of the control bytes. > > Since we're on the subject - can we dump the control bytes? A chunk > system: > * Send 2 bytes of length of incomming data or 0 to signal > CB_RESTARTED > * Send that many bytes of data > > Makes the checkering and stripping code simplier and so means that > nodes don't have to pad to the end of a block when something goes > wrong. All in all it would just be neater design unless someone has a > great reason for control bytes which I'm missing.
No, we can't have this. Such a system means that a whole part has to received before it can be sent out. That makes sense of FCP, but in FNP we need to start returning the data as soon as possible (or we end up in another situation where we have to wait for an unspecified amount of time - if you have 15 hops and a part takes 5 seconds, then that will be an extra 75 seconds at the client before the data comes). Padding to the end of the block is not hard. Stop complaining. > > Doh! Since we're padding the document out to a power of 2 (presumably > > with zeroes ??) > > Zeros is reasonable since the padding is pre-encryption. But it does > give a known-plaintext attack. Since the padding is disguarded it's > upto the client to decide what to pad with - but I'd suggest something > at least slightly random. God knows there is enough known plaintext in there already. I think we can trust AES... -- 'DeCSS would be fine. Where is it?' 'Here,' Montag touched his head. 'Ah,' Granger smiled and nodded. Oskar Sandberg md98-osa at nada.kth.se _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
