[Bug classpath/23899] BouncyCastle crypto library errors

[gnu at frogcircus dot org]

------- Comment #7 from gnu at frogcircus dot org  2006-04-19 02:51 -------
Subject: Re:  BouncyCastle crypto library errors

FWIW, here is the response that I got from the BouncyCastle mailing list
when I shared comment number 3. Could someone help me understand whether
or not any of his points regarding changes that should be made to
Classpath are valid? I lack the expertise to carefully analyze his
feedback.

thanks,
Charles


--------------------------------------------------------------------------------
Hi Charles,

I wasn't able to setup and run any of the free JVMs, and I only really 
examined DSATest - however comparing source b/w Sun and Classpath class 
libraries makes the problem clear.

Comment #3 below is pretty close to the mark, but there's a few things 
to point out for any interested readers:

- Ok, first off, obviously  the anonymous instance of SecureRandom used 
in DSATest is, I guess, particularly bad as it essentially assumes there 
will be exactly two calls to nextBytes for known numbers of bytes. It 
would be an improvement to at least remove the assumption that there 
will be exactly two calls to get all those bytes. Let's assume that's done.

- The implementation of BigInteger(int, Random) in the Classpath 
libraries calls Random.nextInt() to get 32 bits of random data at a 
time, whilst the Sun implementation calls Random.nextBytes(). If the 
number of bits being asked for was not a multiple of 32, there would be 
immediate problems here, due to different approaches to discarding 
excess bits, but in these crypto tests I believe the number of bits will 
in fact be a multiple of 32. Still, using Random.nextInt() actually 
turns out to be a problem, because that calls Random.next(int) (as 
'required' by the API docs for Random), and....

- Looking at SecureRandom.next(int), we see that for Sun's JVM, 
SecureRandom.next(int) is implemented by calling 
SecureRandom.nextBytes(byte[]), whereas in Classpath, 
SecureRandom.next(int) calls nextBytes on the underlying engine 
directly, NOT SecureRandom.nextBytes.
The idiom used in these tests i.e.
    SecureRandom random = new SecureRandom() { public void 
nextBytes(byte[])...}
relies on overriding the default implementation of nextBytes to deliver 
the predetermined 'random' bytes, but this attempt to override fails 
when using the Classpath libs, since BigInteger is using nextInt() to 
get the bytes.
    The API docs for SecureRandom do say about nextBytes() that 'This 
method is used as the basis of all random entities returned by this 
class'. I think an argument can be made that it is a bug in Classpath 
that overriding SecureRandom.nextBytes does not result ultimately in 
intercepting any request for nextInt().

 > on whether or not this code should be JVM independent?

I think the short answer is - it's not entirely independent. It would be 
better for BouncyCastle not to rely too tightly on the implementation 
details of BigInteger(int, Random).

However, it seems to me that if one accepts that the SecureRandom 
implementation in Classpath is in error and fixes it (and the overly 
narrow assumptions in DSATest described above and in any other tests), 
the tests might actually work (the BigInteger differences shouldn't 
cause a problem with 32-bit aligned keysizes).

Sorry if that's hard to read, it's late here :o).

Actually I just noticed that Kaffe 1.1.7 includes an implementation of 
BigInteger from "GNU MP" also. Looking at the source for that alternate 
version, the BigInteger(int, Random) constructor seems more compatible 
with the JDK one, or maybe it's the other way around. It would make the 
SecureRandom issues moot, since it uses nextBytes() directly.

http://www.kaffe.org/doc/kaffe/FAQ.bignum

Don't know about the other free JVMs though.

Cheers,
Pete.


Charles Fry wrote:
> Greetings,
>
> As part of my efforts to include BouncyCastle in Debian main, I
> discovered that no free JVM is able to pass all of the regression tests,
> which we believe to be due to some Classpath issue. The full details of
> my Classpath bug report can be found at:
>
>     http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23899
>
> Below you will find some recent comments on the bug report suggesting
> that your use of SecureRandom may be JVM dependent. Could someone with a
> good understanding of the pattern used in DSATest (and others) comment
> on whether or not this code should be JVM independent?
>
> Even better, if anyone was willing to at least debug the failed test
> cases under a free JVM, that would be most excelent:
>
>    wget http://www.bouncycastle.org/download/crypto-132.tar.gz
>    tar zxf crypto-132.tar.gz
>    cd crypto-132/jars
>    gij -cp bctest-jdk14-132.jar:bcprov-jdk14-132.jar 
> org.bouncycastle.crypto.test.RegressionTest
>
> As indicated in the bug report referenced above, the erorrs are:
>
> DSA: r component wrong.
>  expecting: 68076202252361894315274692543577577550894681403
>  got      : 746231301394742731982047691450321420276689060848
> ECDSA 192 bit prime: r component wrong.
>  expecting: 3342403536405981729393488334694600415596881826869351677613
>  got      : 6249833018739160226694907120521802919631748840289650662347
> GOST3410-TEST1-512: r component wrong.
>  expecting: 3e5f895e276d81d2d52c0763270a458157b784c57abdbd807bc44fd43a32ac06
>  got      : 24287d8a0d17fedec7c6dfd5a018a27ddcca4528a84ae7a51344715a83de2456
> ECGOST3410 - TEST: r component wrong.
>  expecting:
> 29700980915817952874371204983938256990422752107994319651632687982059210933395 
>  got      :
> 13628253036095457453781547057345293906187223953521072753797672813397452752475
>
>
> Any assistance on this matter would be appreciated.
>
> Charles
>
>
> ------- Comment #3 from csm at gnu dot org  2006-04-17 23:49 -------
> In all the tests that fail, I see that they are using `SecureRandom'
> implementations that return predefined values. E.g, in DSATest, there is this
> code:
>
>     SecureRandom    random = new SecureRandom()
>     {
>         boolean first = true;
>
>         public void nextBytes(byte[] bytes)
>         {
>             byte[] k1 = 
> Hex.decode("d5014e4b60ef2ba8b6211b4062ba3224e0427dd3");
>             byte[] k2 =
> Hex.decode("345e8d05c075c3a508df729a1685690e68fcfb8c8117847e89063bca1f85d968fd281540b6e13bd1af989a1fbf17e06462bf511f9d0b140fb48ac1b1baa5bded");
>
>             if (first)
>             {
>                 System.arraycopy(k1, 0, bytes, 0, k1.length);
>                 first = false;
>             }
>             else
>             {
>                 System.arraycopy(k2, 0, bytes, 0, k2.length);
>             }
>         }
>     };
>
> I would guess that the way Classpath uses this SecureRandom is different than
> the way Sun's VM does, possibly in the `BigInteger' constructor that generates
> a random MP integer.
>
>
>   


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23899