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
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
