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'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

Index: src/freenet/crypt/ciphers/Rijndael.java
===================================================================
--- src/freenet/crypt/ciphers/Rijndael.java	(revision 11582)
+++ src/freenet/crypt/ciphers/Rijndael.java	(working copy)
@@ -67,10 +67,27 @@
 	}
     }
 
+private static final char[] HEX_DIGITS = {
+        '0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'
+    };
+    
+    private static String pb(byte[] ba) {
+        int length = ba.length;
+        char[] buf = new char[length * 2];
+        for (int i = 0, j = 0, k; i < length; ) {
+            k = ba[i++];
+            buf[j++] = HEX_DIGITS[(k >>> 4) & 0x0F];
+            buf[j++] = HEX_DIGITS[ k        & 0x0F];
+        }
+	return new String(buf);
+    }
+
     public synchronized final void encipher(byte[] block, byte[] result) {
+System.out.println("in  "+pb(block)+" ("+block.length);
         if(block.length != blocksize/8)
             throw new IllegalArgumentException();
 	Rijndael_Algorithm.blockEncrypt(block, result, 0, sessionKey);
+System.out.println("out "+pb(result)+" ("+result.length+"\n\n\n\n");
     }
 
     public synchronized final void decipher(byte[] block, byte[] result) {

Attachment: pgplE9zqDv6C1.pgp
Description: PGP signature

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to