On Thursday 05 Apr 2012 18:56:23 Chetan Hosmani wrote: > 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).
AES is Rijndael with a 128-bit block size. If JCA lets you use a 256-bit block size, it's not (strictly speaking) AES. Anyway, if it lets you do that, then we can replace all of the code that uses Rijndael, and get rid of the Rijndael code - this is good, provided that the performance is not less than what we get now. > > ->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. If it is 256/256, then it's exactly the same as we were using. So there is no need for a new negotiation type: it should work fine with the JCA code talking to nodes using the old java code. What I had expected for neg type 8 was 256/128 i.e. standard AES, 256-bit key, 128-bit block size. This would require using CFB implemented through JCA, rather than our PCFB implementation. > > 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. Yes. If we are going to replace the Rijndael code globally with JCA then we need a benchmark of the JCA version versus the current java version. > > 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. At the cost of more memory usage. You could create the ciphers lazily, perhaps (i.e. not create them until you need them). Or change the API - but the advantage of using the same BlockCipher API is that it's really easy to swap it out. Another option is to use a weak reference. I suspect that reinitialising on each block will have a fairly large performance cost, so you need to find some way around this. > > I ll test each of them for performance and post them here. Benchmark the ciphers themselves, not the node. But it would be very nice if we could get rid of Rijndael without any backwards compatibility issues. > > 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120407/3d6d966d/attachment.pgp>
