GOST cipher & related added.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux