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 loong 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 <[EMAIL PROTECTED]>
pgpZRxNHNxsP2.pgp
Description: PGP signature
