Of course, this had to come at about the same time that Raif made a bunch of changes to various crypto-related files and scared the hell out of me thinking that I was suddenly going to have a merge conflict. :-P In general: The full output of cvs diff -uN classpath > blah is available here: http://www.surgo.net/classpath/cvsdiffoutput.diff For some reason, the -N option doesn't seem to be working so the additional files are all available here: http://www.surgo.net/classpath/GOST.java http://www.surgo.net/classpath/GOSTSpi.java http://www.surgo.net/classpath/GOSTKeyGeneratorImpl.java http://www.surgo.net/classpath/GOSTSecretKeyFactoryImpl.java http://www.surgo.net/classpath/OMacGOSTImpl.java (Where to put them is said in the top of the diff file, at least.) Sum of changes: * Complete addition of the GOST block cipher. * Addition of method addTwoUnsignedIntegers to Util.java * Addition of method copyIntToBytes to Util.java (More than one other file duplicates this functionality unnecessarily.) * Addition of method toIntFromBytes to Util.java (More than one other file duplicates this functionality unnecessarily.) * Making PBES2.java use only one coding style. I'll get to modifying the duplicates in the other files to use the new Util.java code one of these days, it didn't seem proper to put it in with this change. On my GOST implementation: I'd really like Casey or Raif or both to check this to make sure it actually works as it's supposed to. It decrypts what it encrypts, but testing to actually make sure that the encryption function works as it's supposed to is made quite difficult by the lack of official test vectors. It seems correct, everything is done exactly as described in Schneier's book and the translated spec, but looks can be deceiving and the lack of test vectors is a real pain. If it means anything, all of the implementation problems I had (stuff not decrypting correctly) were due to stupid things I did in Util.java, not GOST.java. All of which have obviously been corrected now, and in correcting I compared my implementation to the specification MANY times. Do note that most implementations of GOST will not generate working test vectors for my implementation due to different S-Boxes; they're all based on the code in the back of Applied Cryptography (reference [1] in GOST.java), which contains different S-Boxes than the ones actually specified in Applied Cryptography (which are the ones that I've used for my implementaton). I wrote a Mauve test case to make sure things decrypted correctly, but Mauve doesn't seem to work for me (every block cipher times out), so I just wrote this to test and print stuff: http://www.surgo.net/classpath/test.java I took that specific vector from crypto++ (public domain), but again, no idea what the ciphertext there is supposed to mean. It might not mean anything: crypto++ has an implementation using four 256-element lookup tables instead of S-Boxes; I also didn't see that 11-bit left-circular shift at the end, but this could easily be due to the tables. So, once again, I'd appreciate it if Casey or Raif or both could double-check my implementation. Difficulties found while implementing this: (1) The number of files you have to modify to add a single block cipher, while managable, is excessive. It would be great if we could just modify (Registry) and have everything derived from there. Failing that, there really needs to be documentation on how to add these things -- I just grepped all of classpath for "blowfish" and added GOST in everywhere blowfish was. (2) The file gnu/javax/crypto/jce/cipher/PBES2.java is absolutely out of hand. This ties into (1) but is even worse if you want to add a new one-way hash function to the library. A part of me says that there has to be a better way to do this, but I'm not sure, mostly because I don't know how any of the HMac infrastructure works. All of the problems with this file carry over to the gnu/javax/crypto/jce/GnuCrypto.java file. It looks to me like the only thing this loooooong use of static inner classes is for is for setting up the GnuCrypto provider for PBES2 ciphers. Could this not be done instead with some sort of much more easy-to-manage list (the data type), possibly one that fills itself from (Registry)? Casey, Raif, what do you guys think of this? (3) There are also a good deal of nearly-empty files you have to add when you add a new block cipher, mostly due to the JCE interface. It looks to me like a lot of the work could be done by an AWK or Perl script. Not necessarily a complaint per-se (I guess it's a necessary evil of implementing JCE), just a comment. Well, that's all for now. -- Morgon Kanter <morgon@xxxxxxxxx> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available Url : http://developer.classpath.org/pipermail/classpath/attachments/20060604/0e224620/attachment.pgp
