This does appear to be real, I am working on a (backwards compatible) fix. On Tue, Jan 09, 2007 at 12:40:46AM +0000, Matthew Toseland wrote: > On Mon, Jan 08, 2007 at 11:31:14PM +0000, Dave Baker wrote: > > On Monday 08 January 2007 18:42, Robert Hailey wrote: > > > > > > Please excuse me if this has already been addressed, I'm just now > > > starting to dig into the freenet source. > > > > > > The encryption aspect interests me, but after writing a test program > > > and testing various key/block sizes for Rijndael, I found that only > > > the 128 bit block size appears to work as it stands in the SVN > > > repository, yet everywhere that it is used in the rest of the source > > > it is requested with a 256 blocksize. > > > > > > Apparently only due to not passing the blocksize into the key/encrypt/ > > > decrypt functions, it appears easy enough to fix (example patch > > > included). My question is, why aren't these other classes which rely > > > on Rijndael-256-block encryption broken? or are they, silently? > > > > > > If I'm missing something obvious, please do tell. > > > > Eep. > > > > I've looked at it and I think you're absolutely correct. It seems every use > > of > > Rijndael in Freenet in through the PCFBMode class, which complicates things > > a > > little. I've managed to get as far as establishing that indeed in all the > > 256 > > bit AES encryptions that freenet does, only the first 128 bits ever get > > encrypted. Because of the Periodic Cipher Feedback, this means that only > > the > > first part of the feedback register gets encrypted. Presumably, the reverse > > happens on decryption, which means that the correct plaintext is obtained > > correctly at the end. In fact, if you use the same array for the input and > > output in your test program, it passes. > > I'm not convinced. > > We *DO* use ECB mode in one place in the code. That place happens to be > critical to the node's function: > > Packet hash encryption! > > The first 32 bytes of every packet are an ECB-encrypted hash of the > encrypted rest of the packet. > > We decrypt this and check it; if it does not match, the packet is > rejected and an error is logged. > > Thus if this is true, no packet would ever be accepted. > > > > I've attatched a patch which shows the debugging I added to come to this > > result (basically just uses your binary-to-hex converter to print the input > > and output of Rijandael.encipher). > > > > The reason why your test fails is because your result array starts as > > zeroes, > > whereas PCFB mode uses the feedback register for both the input and output, > > meaning that the bytes in the result array that aren't written to remain as > > the input. > > > > I don't know enough about periodic cipher feedback theory mode to comment > > on > > the implications of only encrypting half the feedback register, but it > > surely > > must decrease the security massively. > > > > So whilst your patch makes the node encrypt correctly, it means it can't > > read > > the store or talk to any of its peers, since they're all using the old > > encryption 'algorithm'. > > > > Unless I'm also barking up the wrong tree, I have a horrible feeling of > > impending content reset. > > > > Dave
> _______________________________________________ > Devl mailing list > [email protected] > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
