[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    Re: AW: [dev-crypto] Problems with X509Certificate.hashCode()
From:       David Hook <dgh () lockboxlabs ! com>
Date:       2010-08-30 4:22:17
Message-ID: 1283142137.2036.43.camel () konkolo
[Download RAW message or body]


This should now be corrected in the latest beta.

The new beta is now available at http://www.bouncycastle.org/betas

equals/hashCode got added a long time ago, from memory it was a problem
with one of the intermediate releases of the JDK that caused the
overrides to be introduced.

Regards,

David

On Fri, 2010-08-27 at 16:21 +0200, Steffen Heil wrote:
> Hi
> 
>  
> 
> Both implementations compare certificates based on their encoded form,
> so a.equals(b) does check that both are equal, when they are
> reencoded.
> 
> It is only the hashCode() function that is implemented differently.
> 
>  
> 
> JDK:    s = 0, \foreach i \in ]0..l[ : s += e[i] * I
> 
> BC:   s = 0, \foreach I \in [0..l[ : s = s*257 + e[i]
> 
>  
> 
> With e = certificate.getEncoded(), l = e.length().
> 
>  
> 
> Therefor dropping the overridden hashCode function would solve
> everything.
> 
> (There was a bug closed in one of the latest versions saying that the
> hashCode function was "improved", but I don't know, if reverting to
> the JDK default behavior will break this improvement.)
> 
>  
> 
> Also note, that the Sun JRE offers a default implementation of
> hashCode() which would not have to be overwritten, that seems okay for
> me. Other JDKs might have worse implementations that were better
> overwritten, but then the problem would occur there.
> 
>  
> 
> If the BC libraries want to be compatible with every JRE and want to
> fulfill the requirements usually given by hashCode and equals, they
> simply MAY NOT override hashCode at all. Implementing getEncoded() is
> enough, but this is required and done anyway.
> 
>  
> 
> Regards,
> 
>   Steffen
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Von: Maarten Bodewes [mailto:maarten.bodewes@gmail.com] 
> Gesendet: Freitag, 27. August 2010 16:06
> Cc: dev-crypto@bouncycastle.org
> Betreff: Re: [dev-crypto] Problems with X509Certificate.hashCode()
> 
> 
>  
> 
> Did you try and reencode said certificates? Are they all binary
> compatible afterwards? Or is it the problem of the hashCode() method
> entirely?
> 
>         On Aug 26, 2010 10:55 PM, "Steffen Heil"
>         <lists@steffen-heil.de> wrote:
>         
>         Hi
>         
>         Bouncycastle's X509CertificateObject overwrites
>         X509Certificates hashCode()
>         and equals().
>         
>         While equals() is consistent with the VMs implementation of
>         equals (this is
>         a.equals(b) == b.equals(a) for a instanceof
>         BC.X509CertificateObject and b
>         instanceof SUN.X509CertImpl), it is not consistent with that
>         implementation
>         of hashCode().
>         
>         http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode(
>         ) mandates:
>         "If two objects are equal according to the equals(Object)
>         method, then
>         calling the hashCode method on each of the two objects must
>         produce the same
>         integer result."
>         
>         However, BC.X509CertificateObject overwrites
>         Certificate.hashCode with a
>         different behavior. This can result in the following:
>         
>         X509Certificate a = .... // gotten from BC
>         X509Certificate b = .... // gotten from Sun JRE
>         
>         a.equals(b) && b.equals(a) &&  a.hashCode() != b.hashCode()
>         
>         The obvious fix is to remove the hashCode() overriding in
>         X509CertificateObject OR to implement it the same way, sun
>         does.
>         This is especially a problem when dealing with HashMaps...
>         
>         Any hints to circumvent this or any reason to hope for a soon
>         fix?
>         
>         Regards,
>           Steffen
>         




[prev in list] [next in list] [prev in thread] [next in thread]