* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-01-09 17:41:23]: > I want to hazard a word because no else does it: how many of such > problems could be still in the code?
plenty > I think there is no answer to this question. You asked how many could be, right ? My answer seems to be appropriate. > Maybe toad or someone else (maybe paid from the donations) should do a > careful code review, at least of the critical security parts. We ought to introduce unit tests on the new code we are writing that's for sure... and it would be great if we were writing one test for every bug we fix. > 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). Read below. > Even if it is alpha, everyone thinks it is secure and anonymous. And > until this is sure, new users should be advised to use 0.5, the stable > version. ROFL. Are you aware that 0.5 is using the same code ? :) We have hit the bug on 0.7 because the keysize is different, that's all. > 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? 0.5 is harvestable, we do have evidence that its routing *doesn't* work as well as it ought to. 0.5 has been reviewed ? by whom ? Have I already mentionned that this precise part of the code is mostly borrowed from 0.5 ? > 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. No, I am not going to write down a "howto bring 0.5 down" tutorial for you :) and I wouldn't encourage anyone to do so. It's not a direct comparison but it's probably instructive for most people who will take part to that thread. http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity It has been out of here since a while... Of course it doesn't tell anything about bugs like that one. On 0.5 we were using 128bits AES, on 0.7 we were supposed to be using 256bits (in reality we were using a "custom" algorithm because of the bug... and noone knows how weak it is). On 0.5 we were using SHA1 on 0.7 we are using SHA256. > > 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
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
