[freenet-dev] Rijndael cipher broken

[Matthew Toseland]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070109/ecfac4f8/attachment.pgp