Re: Re: Public Key Extraction in Implicit Certificates (ECQV)

Hi Manuel,
That is a very strange result!

As far as I can see, BC_CA_PUBLIC_KEY is a valid public key, do you have
any other sect163k1 implementations to hand to confirm/contradict that?

The RECOVERED_KEY from BC_CA_PUBLIC_KEY is invalid because its order is
2N instead of N (this curve has cofactor 2). The point of order 2 is
(0,1) on this curve, but RECOVERED_KEY is not that, nor is it
(BC_CA_PUBLIC_KEY + (0,1)).

Which means the "public key reconstruction data" would have to be
invalid; not just with incorrect order, but actually not even a point on
the curve - but did you use the same certificate in each test or
generate separate ones? (Using different procedures?)

Could you provide the certificate(s) for these cases please.

If you are able to do more tests, could you please try this hash==0 test
with the basepoint (G) as the CA:
    0302FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8

Also, if you try it for many (100s) newly-generated BC CA keys, does it
always fail i.e. RECOVERED_KEY is different?

Regards,
Pete Dettman

On 17/7/19 5:51 pm, biscas wrote:
> Hi Peter,
> 
> Regarding Point 3, we have made the suggested test, that is:
> 
> int dummy_hash(unsigned char *digest, unsigned long int sz, unsigned char
> *dat){
>     memset(digest,0,16);
>     return 0;
> }
> 
> ZSE_ECQVReconstructPublicKey(u_certificate,ca_PublicKey,u_recoveredPublicKey1,dummy_hash,
> yield, YIELD_LEVEL);
> 
> If CA_Public_Key is a Public Key generated via BouncyCastle, for instance:
> 
> BC_CA_PUBLIC_KEY:
> 03:03:8B:06:D2:86:55:52:31:3C:0A:13:E6:2B:22:F4:48:DE:CB:D1:E1:77
> RECOVERED_KEY:
> 03:06:79:D1:85:B2:E5:9F:F1:94:1C:07:FA:DE:E1:80:4A:32:9D:A4:97:11
> RECOVERED KEY is different from the BC_CA_PUBLIC_KEY AND BouncyCastle deems
> it to be invalid.
> 
> CERTICOM_CA_PUBLIC_KEY:
> 02:00:FD:E8:A7:F3:D1:08:42:24:96:2A:4E:7C:54:E6:9A:C3:F0:4D:A6:B8
> RECOVERED_KEY:
> 02:00:FD:E8:A7:F3:D1:08:42:24:96:2A:4E:7C:54:E6:9A:C3:F0:4D:A6:B8
> 
> If on the other side, CERTICOM_CA_PUBLIC_KEY is used as input, output
> matches input. Moreover the CERTICOM_CA_PUBLIC_KEY is a valid one according
> to BouncyCastle. This at least explains why the developed BC Verifier is
> able to verify signatures from certificates emitted by Certicom.
> 
> 
> 
> 
> --
> Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html
>