NoSuchFieldError BigInteger.ONE in J2ME package on Nokia S40

[Christian Werner]

Hello,

I implemented a ECC encryption on J2ME using Bouncycastle. On Nokia S60
phones and in emulator its working fine, but on Nokia S40 I get the
following exception:
java/lang/NoSuchFieldError: No such field
ONE.Lorg/bouncycastle/math/BigInteger;.

I moved BigInteger to org.bouncycastle.math package, so I don't have to
obfuscate it which is horrible for tracing errors.

I tried Bouncycastle 1.35 and 1.42 and also BigInteger of 1.44 - but
nowhere it's working.

The following code seems to create the problem:

public final static ECCurve FP192_V1 = new ECCurve.Fp(
                new
BigInteger("6277101735386680763835789423207666416083908700390324961279"),
                new
BigInteger("fffffffffffffffffffffffffffffffefffffffffffffffc", 16),
                new
BigInteger("64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1", 16));

public final static ECDomainParameters PRIME192_V1_BASED_DOMAIN_PARAMS =
new ECDomainParameters(
                FP192_V1,
                    FP192_V1.decodePoint(
                   
Hex.decode("03188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012")),
                new
BigInteger("ffffffffffffffffffffffff99def836146bc9b1b4d22831", 16));

... but this are the standard constants also used in X962NamedCurves
class ...

What I'm wondering is, that this exception is NOT caught with a general
exception. Also I'm using Netbeans and I can not compile catching the
NoSuchFieldError exception, since it does not exist. Also what I
understood is, that this exception should be prevented by compiler in
most cases: "Normally, this error is caught by the compiler; this error
can only occur at run time if the definition of a class has incompatibly
changed." But where the class is changed at runtime and I also wonder if
this is possible in J2ME (MIDP2)...

Maybe someone can help or sees a bug in what I did - or it's a bug in
Bouncycastle?!

Regards,

Christian Werner

[David Hook-2]

The field ONE definitely exists in 1.44. Can't really suggest anything,
other than you carefully check the jars/zips you're using, it sounds
like one of them is either out of date, or not what you think it is.

Regards,

David

On Mon, 2009-11-02 at 17:05 +0100, Christian Werner wrote:

> Hello,
>
> I implemented a ECC encryption on J2ME using Bouncycastle. On Nokia S60
> phones and in emulator its working fine, but on Nokia S40 I get the
> following exception:
> java/lang/NoSuchFieldError: No such field
> ONE.Lorg/bouncycastle/math/BigInteger;.
>
> I moved BigInteger to org.bouncycastle.math package, so I don't have to
> obfuscate it which is horrible for tracing errors.
>
> I tried Bouncycastle 1.35 and 1.42 and also BigInteger of 1.44 - but
> nowhere it's working.
>
> The following code seems to create the problem:
>
> public final static ECCurve FP192_V1 = new ECCurve.Fp(
>                 new
> BigInteger("6277101735386680763835789423207666416083908700390324961279"),
>                 new
> BigInteger("fffffffffffffffffffffffffffffffefffffffffffffffc", 16),
>                 new
> BigInteger("64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1", 16));
>
> public final static ECDomainParameters PRIME192_V1_BASED_DOMAIN_PARAMS =
> new ECDomainParameters(
>                 FP192_V1,
>                     FP192_V1.decodePoint(
>                    
> Hex.decode("03188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012")),
>                 new
> BigInteger("ffffffffffffffffffffffff99def836146bc9b1b4d22831", 16));
>
> ... but this are the standard constants also used in X962NamedCurves
> class ...
>
> What I'm wondering is, that this exception is NOT caught with a general
> exception. Also I'm using Netbeans and I can not compile catching the
> NoSuchFieldError exception, since it does not exist. Also what I
> understood is, that this exception should be prevented by compiler in
> most cases: "Normally, this error is caught by the compiler; this error
> can only occur at run time if the definition of a class has incompatibly
> changed." But where the class is changed at runtime and I also wonder if
> this is possible in J2ME (MIDP2)...
>
> Maybe someone can help or sees a bug in what I did - or it's a bug in
> Bouncycastle?!
>
> Regards,
>
> Christian Werner
>

[Lothar Kimmeringer-4]

Christian Werner schrieb:

> I implemented a ECC encryption on J2ME using Bouncycastle. On Nokia S60
> phones and in emulator its working fine, but on Nokia S40 I get the
> following exception:
> java/lang/NoSuchFieldError: No such field
> ONE.Lorg/bouncycastle/math/BigInteger;.
>
> I moved BigInteger to org.bouncycastle.math package, so I don't have to
> obfuscate it which is horrible for tracing errors.

Not sure if I understand that correctly. You moved
java.math.BigInteger to org.bouncycastle.math?

Or are we talking about org.bouncycastle.util.BigIntegers?
BigIntegers doesn't contain ONE, but ECCConstants does
(using BigInteger.valueOf(1)).
The whole codebase of BouncyCastle (I have the CVS-version
here) don't use java.math.BigInteger.ONE, so I don't think
that BouncyCastle can be "fixed" by establishing a workaround.

> I tried Bouncycastle 1.35 and 1.42 and also BigInteger of 1.44 - but
> nowhere it's working.

If we are really talking about java.math.BigInteger it seems
that the JVM in that specific Nokia device lacks this field
which would be a bug in the Nokia device.

>
> The following code seems to create the problem:
>
> public final static ECCurve FP192_V1 = new ECCurve.Fp(
>                new
> BigInteger("6277101735386680763835789423207666416083908700390324961279"),
>                new
> BigInteger("fffffffffffffffffffffffffffffffefffffffffffffffc", 16),
>                new
> BigInteger("64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1", 16));

I don't see BigInteger.ONE there.

> public final static ECDomainParameters PRIME192_V1_BASED_DOMAIN_PARAMS =
> new ECDomainParameters(
>                FP192_V1,
>                    FP192_V1.decodePoint(
>                  
> Hex.decode("03188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012")),
>                new
> BigInteger("ffffffffffffffffffffffff99def836146bc9b1b4d22831", 16));
>
> ... but this are the standard constants also used in X962NamedCurves
> class ...

There is no BigInteger.ONE, either.

> What I'm wondering is, that this exception is NOT caught with a general
> exception.

It's an error that is derived from Throwable and not Exception.

> Also I'm using Netbeans and I can not compile catching the
> NoSuchFieldError exception, since it does not exist.

Sounds strange. You might try catch(Throwable) but preferably
you should first check where the BigInteger.ONE is used any-
way, because it seems more likely to happen in your own code
rather than BC.

> Also what I
> understood is, that this exception should be prevented by compiler in
> most cases: "Normally, this error is caught by the compiler; this error
> can only occur at run time if the definition of a class has incompatibly
> changed." But where the class is changed at runtime and I also wonder if
> this is possible in J2ME (MIDP2)...

The description is a bit confusing. It means that this error can
only happen if you compile against other classes than you use
for execution.
Exactly that seems to be the case here.


Regards, Lothar

[Lothar Kimmeringer-4]

have to answer my own mail ;-)

Lothar Kimmeringer schrieb:
> Christian Werner schrieb:
>
>> I moved BigInteger to org.bouncycastle.math package, so I don't have to
>> obfuscate it which is horrible for tracing errors.
>
> Not sure if I understand that correctly. You moved
> java.math.BigInteger to org.bouncycastle.math?

And if the answer is yes, have you changed all usages
in the BC-classes from java.math.BigInteger to
org.bouncycastle.math.BigInteger? Otherwise java.math.BigInteger
is still used (the one provided by the JVM of the device, which
might be the reason for the NoSuchFieldError-message.

> so I don't think
> that BouncyCastle can be "fixed" by establishing a workaround.

in the meaning of "can't be 'fixed'" of course ;-)


Regards, Lothar

[Christian Werner]

Thanks for your support.

Finally I got it working on Nokia S40 with (modified) BC 1.44!

Some hours I just put some "return null;", compiled, transfered by
bluetooth and tested to find the exact place of the problem. Really
boring job.

Here is the trace to the 'bug':

ECCurve.Fp.decodePoint ->
    case 0x03:
        ...
        ECFieldElement beta = alpha.sqrt(); ->
            ...
            if (q.testBit(1))
                here you find a 'ONE', if I replace this with
BigInteger.ONE it is working!
               
Everywhere else in ECFieldElement ECConstants.ONE is used and no where
only ONE.
Maybe it's possible to change this in future versions of Bouncy Castle.

So in org.bouncycastle.math.ec.ECFieldElement in function sqrt() at line
123 the 'ONE' should become a 'ECConstants.ONE' or 'BigInteger.ONE'. Not
sure why this works on S60 (Symbian) phones (E71,N95,N73,...) like it is
and on S40 (6288,2630,6280,...) not.


Replying to your mails:

Didn't mess with (old) files/jars.

I found two ONE's - one is in BigInteger itself, the other one is
ECConstants.

Yes, I moved java.math.BigInteger somewhere else, so I can run my
application non-obfuscated and see all exceptions plaintext. All
references I also replaced.

In my code was no BigInteger.ONE, but this code forced the exception.
And exception was 'BigInteger.ONE'. Don't know why BigInteger was
mentioned, since the field is there for sure, but maybe because the JVM
could not decide between ECConstants.ONE and BigInteger.ONE.

I tried catch(Exception) and catch(Throwable) to catch the exception.
Unfortunately both did not work. I think this exception is not supported
by J2ME and that's why it can't be caught. Or Nokia thought this
exception needs to be shown to user ;-)

Best regards,

krisha




Lothar Kimmeringer schrieb:

> have to answer my own mail ;-)
>
> Lothar Kimmeringer schrieb:
>  
>> Christian Werner schrieb:
>>
>>    
>>> I moved BigInteger to org.bouncycastle.math package, so I don't have to
>>> obfuscate it which is horrible for tracing errors.
>>>      
>> Not sure if I understand that correctly. You moved
>> java.math.BigInteger to org.bouncycastle.math?
>>    
>
> And if the answer is yes, have you changed all usages
> in the BC-classes from java.math.BigInteger to
> org.bouncycastle.math.BigInteger? Otherwise java.math.BigInteger
> is still used (the one provided by the JVM of the device, which
> might be the reason for the NoSuchFieldError-message.
>
>  
>> so I don't think
>> that BouncyCastle can be "fixed" by establishing a workaround.
>>    
>
> in the meaning of "can't be 'fixed'" of course ;-)
>
>
> Regards, Lothar
>
>
>  

[David Hook-2]

This is actually what it is (the class implements ECConstants...
evidently there is an issue with their class loader).

I've changed it to ECConstants.ONE explicitly, so (hopefully) this will
be the last time you run into this.

Regards,

David

On Wed, 2009-11-04 at 04:02 +0100, Christian Werner wrote:

> Thanks for your support.
>
> Finally I got it working on Nokia S40 with (modified) BC 1.44!
>
> Some hours I just put some "return null;", compiled, transfered by
> bluetooth and tested to find the exact place of the problem. Really
> boring job.
>
> Here is the trace to the 'bug':
>
> ECCurve.Fp.decodePoint ->
>     case 0x03:
>         ...
>         ECFieldElement beta = alpha.sqrt(); ->
>             ...
>             if (q.testBit(1))
>                 here you find a 'ONE', if I replace this with
> BigInteger.ONE it is working!
>                
> Everywhere else in ECFieldElement ECConstants.ONE is used and no where
> only ONE.
> Maybe it's possible to change this in future versions of Bouncy Castle.
>
> So in org.bouncycastle.math.ec.ECFieldElement in function sqrt() at line
> 123 the 'ONE' should become a 'ECConstants.ONE' or 'BigInteger.ONE'. Not
> sure why this works on S60 (Symbian) phones (E71,N95,N73,...) like it is
> and on S40 (6288,2630,6280,...) not.
>
>
> Replying to your mails:
>
> Didn't mess with (old) files/jars.
>
> I found two ONE's - one is in BigInteger itself, the other one is
> ECConstants.
>
> Yes, I moved java.math.BigInteger somewhere else, so I can run my
> application non-obfuscated and see all exceptions plaintext. All
> references I also replaced.
>
> In my code was no BigInteger.ONE, but this code forced the exception.
> And exception was 'BigInteger.ONE'. Don't know why BigInteger was
> mentioned, since the field is there for sure, but maybe because the JVM
> could not decide between ECConstants.ONE and BigInteger.ONE.
>
> I tried catch(Exception) and catch(Throwable) to catch the exception.
> Unfortunately both did not work. I think this exception is not supported
> by J2ME and that's why it can't be caught. Or Nokia thought this
> exception needs to be shown to user ;-)
>
> Best regards,
>
> krisha
>
>
>
>
> Lothar Kimmeringer schrieb:
> > have to answer my own mail ;-)
> >
> > Lothar Kimmeringer schrieb:
> >  
> >> Christian Werner schrieb:
> >>
> >>    
> >>> I moved BigInteger to org.bouncycastle.math package, so I don't have to
> >>> obfuscate it which is horrible for tracing errors.
> >>>      
> >> Not sure if I understand that correctly. You moved
> >> java.math.BigInteger to org.bouncycastle.math?
> >>    
> >
> > And if the answer is yes, have you changed all usages
> > in the BC-classes from java.math.BigInteger to
> > org.bouncycastle.math.BigInteger? Otherwise java.math.BigInteger
> > is still used (the one provided by the JVM of the device, which
> > might be the reason for the NoSuchFieldError-message.
> >
> >  
> >> so I don't think
> >> that BouncyCastle can be "fixed" by establishing a workaround.
> >>    
> >
> > in the meaning of "can't be 'fixed'" of course ;-)
> >
> >
> > Regards, Lothar
> >
> >
> >  
>
>