Hi Sorry but I didn't understand what you meant by (on github)
->This is actually using 256/256 Rijndael, the JVM appears to allow it. Is the JCA encryption same as Rijndael or my code is still using Rijndael instead of JCA? I tested this and JCA was being called. If its same as Rijndael I get what you mean, that a new negtype is not needed. Also I should actually test it with (256, 128). ->probably require switching to the standard CFB mode I am already using JCA in AES CFB mode as the default. Though I am not sure what happens when key = block = 256. I ll check that. I will also try without Rijndael (probably modify Rijndael.java file itself to use JCA, as a temporary hack?). If it works I will benchmark it and then let you know. The initialisation is needed each time for choosing the mode - encrypt or decrypt. But I can initialise two ciphers in JCACipher, one for encryption and another for decryption. So that would make it faster, probably. I ll test each of them for performance and post them here. Thank you On Thu, Apr 5, 2012 at 5:28 PM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Tuesday 03 Apr 2012 22:01:40 Chetan Hosmani wrote: >> Hello, >> >> nextgens as you wanted some changes I have implemented them. I have >> sent a pull request to freenet:next. >> Here is the patch. > > Cool. > > It's here: > https://github.com/freenet/fred-staging/pull/88 > > There was some confusion about this. From your code it appears that we can > just specify a 256 bit block size and the standard code will work. In which > case, the new encryption is exactly the same as the old: 256-bit key, 256-bit > block size, with PCFB mode on top. So you don't need the new negType. Please > test this. If it works, you can use it everywhere in the code, and get rid of > Rijndael, which would be pretty cool. But if so, please benchmark it first: > As I mentioned, are you sure you need to initialise the cipher for each > block? If it's slower in software then we need to keep the old version and > only use the JCA version on startup ... > > I suspect that 256-bit block size isn't hardware accelerated, and certainly > it isn't the standard. So the original plan was to switch to standard AES > (256-bit key, 128-bit block size), which would have required using CFB (which > the JCA probably implements). > > This isn't a criticism anyway. If we can switch to the JVM's AES > implementation without even any back compatibility issues, and without a > performance loss, that would be really nice. >> >> Also wanted some opinion on the idea "Switch from the current code to >> JCA". Since I have been working and reading on this, I thought I ll >> send in a proposal for this task too. Any pointers or suggestions will >> be helpful. I will make a rough draft and mail that too, though there >> is hardly any time left for discussion. > > Well, the above suggests it'd be a fairly small project, although we'd want > to switch some algorithms, such as the above, at the same time. >> >> Thank you
