hello Morgon, the first thing to do if you plan on contributing code to the project is to ensure that copyright assignment papers, for GNU Classpath, are signed. i don't know if you have already done so, but in case you haven't, Mark Wielaard should be able to guide you in that process. On Sunday 04 June 2006 19:50, Morgon Kanter wrote: > 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: my understanding is that GOST is a family of standards that covers things other than crypto. the symmetric block cipher, subject of a GOST standards is really "GOST 28147-89" (there's also a GOST hash algorithm! --GOST R 34.11-94) i recommend you change the name to reflect this, and may be use "GOST" as an alias. > 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). my limited knowledge of GOST 28147-89 is that the (Russian) standard does not mandate one S-box; just the algorithm and may be a default S-box. in this case i suggest you re-use, if you are not already doing so, one publicly published S-box. this way this implementation will be inter-operable with at least another one. > 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. again, in the absence of standardized test vectors, an inter-operability test with another implementation is a must. > 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. may be you would like to write a "How To" document which we can add to the project's wiki? i'll have a look at writing an ANT task that makes this work less complex. > Well, that's all for now. last thing i'd like to say is about the coding style. if you're not already using Eclipse, you can use the EFJ (Eclipse Formatter for Java) <http://www.bagu.org/eclipse/efj/> with the GNU Classpath style available in the scripts/eclipse-gnu.xml. -- cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://developer.classpath.org/pipermail/classpath/attachments/20060605/faef1ac0/attachment.pgp
