On Tue, Jan 09, 2007 at 05:41:23PM +0100, [EMAIL PROTECTED] wrote: > I want to hazard a word because no else does it: how many of such > problems could be still in the code? I think there is no answer to > this question. Maybe toad or someone else (maybe paid from the > donations) should do a careful code review, at least of the critical > security parts.
This particular bug is no longer present in the code, full stop. The reason why is that it was a bug in our wrapper of the Rijndael code. Both the wrapper and the Rijndael code itself were identical in 0.5. 0.5 used 128-bit keys and block sizes, and there was a bug in the wrapper code which assumed that the block size would always be 128 bits (16 bytes), so it used the 128-bit-block version of the functions, even when the block size had been set to a different number than 128. > > And this problem shows that it is unjustifiable to bring users to 0.7 > because they expect a secure network (as advertised in the media). Where did we say Freenet was secure? The best we can say is Freenet is more secure than some other options. There is a brutally honest page on the wiki discussing Freenet's various security issues, for example: http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity > Even if it is alpha, everyone thinks it is secure and anonymous. That is their loss. Alpha software by definition is not fully tested; it has not had as much testing, code review, debugging as beta software, all other things being equal. > And > until this is sure, new users should be advised to use 0.5, the stable > version. We all know that 0.5 is attackable, but the attacks are > mostly statistical attacks, and is'nt this _more_ secure than the > current (unreviewed) 0.7? The attacks on 0.7 are mostly statistical attacks too. This particular bug was a bug in the crypto, which affected link level encryption, and also stored data. In both cases, the attacker can see 16 bytes out of every 32 as plaintext. For link encryption, this is pretty bad; it means a passive snooper can probably get a good idea of what is going on between the two nodes. For stored data, it means it is much easier to identify the original decrypted content. This makes correlation etc attacks easier and makes it easier to identify content in your datastore. > > Sorry if I cried somebody down, but this is my opinion. I like 0.7, > its speed and functionality, but don't mislead the customers that > expect something different. > > If you think I'm wrong then please provide a comparison sheet on the > wiki that compares freenet 0.5 and 0.7 and clearly states why 0.7 is > more secure, even in the current version. > > best regards, bback. > > PS: this mail contains no personal offense, its a constructive business mail. > > > On 1/9/07, Matthew Toseland <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFFovn7A9rUluQ9pFARAjkEAJ95//QHmYIX/NfBZJqe/enCcBryEgCgm7Mq > > uJqiyf1deG5jGwscjVTsuN0= > > =+EVC > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > Devl mailing list > > [email protected] > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > _______________________________________________ > 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
