xmlsec / ECDSA problem

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

xmlsec / ECDSA problem

Miklos Vajna
Hi,

xmlsec from <https://www.aleksey.com/xmlsec/> is a library to verify XML
signatures (and more). It has a number of backends, one of them being
NSS. Currently only the openssl backend of xmlsec supports ECDSA, and
I'm trying to add support for ECDSA in its NSS backend. My first goal
would be verifying a signature I know is valid (since openssl accepts
it).

Here is my work-in-progress code:

https://github.com/vmiklos/xmlsec/commit/fd56f6d42819cbd50b34d471332fb2d948a75a60

If you ignore the boilerplate code, it maps the xmlsec ECDSA key type to
ecKey, the xmlsec ECDSA-SHA256 combined type to
SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATUR.

If you clone that repo, and built it like (on Linux):

./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-gcrypt --without-openssl --enable-debugging
make
cd tests/aleksey-xmldsig-01
../../apps/xmlsec1 verify --trusted-der ../keys/cacert.der --enabled-key-data x509 enveloping-sha256-ecdsa-sha256.xml

is a reproduce for the problem I have. Here are the details I figured
out so far:

- NSS wants the signature data (64 bytes) as a der-encoded pairs of
  integers, so need to encode them before handing over the SECItem to
  NSS in my client code (the above patch already does that).
- Once this is solved, VFY_EndWithSignature() fails with (end of my gdb
  session):

397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
(gdb)
383         SECStatus rv = SECSuccess;
(gdb)
397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
(gdb)
400         if (crv != CKR_OK) {
(gdb) print /x crv
$1 = 0x130
(gdb) bt
#0  PK11_CreateNewObject (slot=slot@entry=0x6929a0, session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, count=count@entry=7, token=token@entry=0,
    objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:400
#1  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
#2  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
    wincx=<optimized out>) at pk11obj.c:736
#3  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
#4  0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360) at secvfy.c:596
#5  0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
    data=0x6b36c0 "\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
    dataSize=64, transformCtx=<optimized out>) at signatures.c:347
#6  0x0000000000443b9a in xmlSecTransformVerifyNodeContent (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710) at transforms.c:1523
#7  0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450, node=<optimized out>) at xmldsig.c:353
#8  0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) at xmlsec.c:1223
#9  0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at xmlsec.c:1058

0x130 is CKR_DOMAIN_PARAMS_INVALID.

Needless to say, if I do the RSA equivalent of this (the name of the
test file in the same directory is enveloping-sha256-rsa-sha256.xml),
then verification works fine.

Any idea what can be the problem here? At least with the distro-provided
nss (which is build with optimization enabled) I can't step into
C_CreateObject() in gdb.

But maybe there is something more fundamental here. :-)

If there is anything above that is not enough for reproducing the
problem, please let me know.

Thanks a lot,

Miklos
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Robert Relyea
On 02/14/2017 03:07 AM, Miklos Vajna wrote:

> Hi,
>
> xmlsec from <https://www.aleksey.com/xmlsec/> is a library to verify XML
> signatures (and more). It has a number of backends, one of them being
> NSS. Currently only the openssl backend of xmlsec supports ECDSA, and
> I'm trying to add support for ECDSA in its NSS backend. My first goal
> would be verifying a signature I know is valid (since openssl accepts
> it).
>
> Here is my work-in-progress code:
>
> https://github.com/vmiklos/xmlsec/commit/fd56f6d42819cbd50b34d471332fb2d948a75a60
>
> If you ignore the boilerplate code, it maps the xmlsec ECDSA key type to
> ecKey, the xmlsec ECDSA-SHA256 combined type to
> SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATUR.
>
> If you clone that repo, and built it like (on Linux):
>
> ./configure --with-pic --disable-shared --disable-crypto-dl --without-libxslt --without-gnutls --without-gcrypt --without-openssl --enable-debugging
> make
> cd tests/aleksey-xmldsig-01
> ../../apps/xmlsec1 verify --trusted-der ../keys/cacert.der --enabled-key-data x509 enveloping-sha256-ecdsa-sha256.xml
>
> is a reproduce for the problem I have. Here are the details I figured
> out so far:
>
> - NSS wants the signature data (64 bytes) as a der-encoded pairs of
>    integers, so need to encode them before handing over the SECItem to
>    NSS in my client code (the above patch already does that).
> - Once this is solved, VFY_EndWithSignature() fails with (end of my gdb
>    session):
>
> 397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
> (gdb)
> 383         SECStatus rv = SECSuccess;
> (gdb)
> 397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
> (gdb)
> 400         if (crv != CKR_OK) {
> (gdb) print /x crv
> $1 = 0x130
> (gdb) bt
> #0  PK11_CreateNewObject (slot=slot@entry=0x6929a0, session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, count=count@entry=7, token=token@entry=0,
>      objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:400
> #1  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
> #2  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
>      wincx=<optimized out>) at pk11obj.c:736
> #3  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
> #4  0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360) at secvfy.c:596
> #5  0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
>      data=0x6b36c0 "\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
>      dataSize=64, transformCtx=<optimized out>) at signatures.c:347
> #6  0x0000000000443b9a in xmlSecTransformVerifyNodeContent (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710) at transforms.c:1523
> #7  0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450, node=<optimized out>) at xmldsig.c:353
> #8  0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) at xmlsec.c:1223
> #9  0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at xmlsec.c:1058
>
> 0x130 is CKR_DOMAIN_PARAMS_INVALID.
>
> Needless to say, if I do the RSA equivalent of this (the name of the
> test file in the same directory is enveloping-sha256-rsa-sha256.xml),
> then verification works fine.
>
> Any idea what can be the problem here? At least with the distro-provided
> nss (which is build with optimization enabled) I can't step into
> C_CreateObject() in gdb.
You would need to install the -debug package for nss-softokn on the
distro to step into softoken (assuming you aren't using a hardware
accellerator).

Fortunately you've provided enough information to get an idea of what is
going on. EC keys have a der encoded parameter telling it what curve the
key is associated with (generally a der encoded oid pointing to the
specific curve). The parameter is in the field u.ec.DerEncodedParams,
and usually applications get this from the spki in a DER certificate, or
a raw spki encoded structure. You'll need to map the xml way of
identifying the curve into the der encoding. NOTE: NSS only supports
what's called the 'named curve' format of the parameters, so if xml is
using raw curve parameters, then you'll have to map the raw curve
parameters into known named curves.

bob
>
> But maybe there is something more fundamental here. :-)
>
> If there is anything above that is not enough for reproducing the
> problem, please let me know.
>
> Thanks a lot,
>
> Miklos


--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Martin Thomson
You might also find this useful
(https://searchfox.org/nss/rev/d4fc405cac1d3da3b7285342b5c70e10b4dae734/lib/ssl/ssl3con.c#1358).
It uses the PK11 interface to verify a signature in TLS.  You might
have to walk backwards to see how inputs are constructed.

On Wed, Feb 15, 2017 at 4:07 AM, Robert Relyea <[hidden email]> wrote:

> On 02/14/2017 03:07 AM, Miklos Vajna wrote:
>>
>> Hi,
>>
>> xmlsec from <https://www.aleksey.com/xmlsec/> is a library to verify XML
>> signatures (and more). It has a number of backends, one of them being
>> NSS. Currently only the openssl backend of xmlsec supports ECDSA, and
>> I'm trying to add support for ECDSA in its NSS backend. My first goal
>> would be verifying a signature I know is valid (since openssl accepts
>> it).
>>
>> Here is my work-in-progress code:
>>
>>
>> https://github.com/vmiklos/xmlsec/commit/fd56f6d42819cbd50b34d471332fb2d948a75a60
>>
>> If you ignore the boilerplate code, it maps the xmlsec ECDSA key type to
>> ecKey, the xmlsec ECDSA-SHA256 combined type to
>> SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATUR.
>>
>> If you clone that repo, and built it like (on Linux):
>>
>> ./configure --with-pic --disable-shared --disable-crypto-dl
>> --without-libxslt --without-gnutls --without-gcrypt --without-openssl
>> --enable-debugging
>> make
>> cd tests/aleksey-xmldsig-01
>> ../../apps/xmlsec1 verify --trusted-der ../keys/cacert.der
>> --enabled-key-data x509 enveloping-sha256-ecdsa-sha256.xml
>>
>> is a reproduce for the problem I have. Here are the details I figured
>> out so far:
>>
>> - NSS wants the signature data (64 bytes) as a der-encoded pairs of
>>    integers, so need to encode them before handing over the SECItem to
>>    NSS in my client code (the above patch already does that).
>> - Once this is solved, VFY_EndWithSignature() fails with (end of my gdb
>>    session):
>>
>> 397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
>> (gdb)
>> 383         SECStatus rv = SECSuccess;
>> (gdb)
>> 397         crv = PK11_GETTAB(slot)->C_CreateObject(rwsession,
>> (gdb)
>> 400         if (crv != CKR_OK) {
>> (gdb) print /x crv
>> $1 = 0x130
>> (gdb) bt
>> #0  PK11_CreateNewObject (slot=slot@entry=0x6929a0,
>> session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0,
>> count=count@entry=7, token=token@entry=0,
>>      objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:400
>> #1  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0,
>> pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
>> #2  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0,
>> mechanism=<optimized out>, param=param@entry=0x0,
>> sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
>>      wincx=<optimized out>) at pk11obj.c:736
>> #3  0x00007ffff768e99e in PK11_Verify (key=<optimized out>,
>> sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
>> wincx=<optimized out>) at pk11obj.c:690
>> #4  0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70,
>> sig=sig@entry=0x7fffffffd360) at secvfy.c:596
>> #5  0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
>>      data=0x6b36c0
>> "\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
>>      dataSize=64, transformCtx=<optimized out>) at signatures.c:347
>> #6  0x0000000000443b9a in xmlSecTransformVerifyNodeContent
>> (transform=0x6ab4d0, node=<optimized out>,
>> transformCtx=transformCtx@entry=0x7fffffffd710) at transforms.c:1523
>> #7  0x000000000044e0f4 in xmlSecDSigCtxVerify
>> (dsigCtx=dsigCtx@entry=0x7fffffffd450, node=<optimized out>) at
>> xmldsig.c:353
>> #8  0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>)
>> at xmlsec.c:1223
>> #9  0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at
>> xmlsec.c:1058
>>
>> 0x130 is CKR_DOMAIN_PARAMS_INVALID.
>>
>> Needless to say, if I do the RSA equivalent of this (the name of the
>> test file in the same directory is enveloping-sha256-rsa-sha256.xml),
>> then verification works fine.
>>
>> Any idea what can be the problem here? At least with the distro-provided
>> nss (which is build with optimization enabled) I can't step into
>> C_CreateObject() in gdb.
>
> You would need to install the -debug package for nss-softokn on the distro
> to step into softoken (assuming you aren't using a hardware accellerator).
>
> Fortunately you've provided enough information to get an idea of what is
> going on. EC keys have a der encoded parameter telling it what curve the key
> is associated with (generally a der encoded oid pointing to the specific
> curve). The parameter is in the field u.ec.DerEncodedParams, and usually
> applications get this from the spki in a DER certificate, or a raw spki
> encoded structure. You'll need to map the xml way of identifying the curve
> into the der encoding. NOTE: NSS only supports what's called the 'named
> curve' format of the parameters, so if xml is using raw curve parameters,
> then you'll have to map the raw curve parameters into known named curves.
>
> bob
>
>>
>> But maybe there is something more fundamental here. :-)
>>
>> If there is anything above that is not enough for reproducing the
>> problem, please let me know.
>>
>> Thanks a lot,
>>
>> Miklos
>
>
>
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Miklos Vajna
In reply to this post by Robert Relyea
Hi,

On Tue, Feb 14, 2017 at 09:07:24AM -0800, Robert Relyea <[hidden email]> wrote:
> You would need to install the -debug package for nss-softokn on the distro
> to step into softoken (assuming you aren't using a hardware accellerator).

Thanks, I didn't realize there are multiple -debuginfo packages for the
same -debugsource ones.

So here is exactly how CKR_DOMAIN_PARAMS_INVALID is set:

----
(gdb) next    
1789                if (EC_FillParams(arena, &pubKey->u.ec.ecParams.DEREncoding,
(gdb) next    
1791                    crv = CKR_DOMAIN_PARAMS_INVALID;
(gdb)
1789                if (EC_FillParams(arena, &pubKey->u.ec.ecParams.DEREncoding,
(gdb) print crv
$5 = 0
(gdb) next    
1841        *crvp = crv;
(gdb) print crv
$6 = 304
(gdb) bt
#0  sftk_GetPubKey (object=object@entry=0x6b4fa0, key_type=key_type@entry=3, crvp=crvp@entry=0x7fffffffced0) at pkcs11.c:1841
#1  0x00007ffff572be7c in sftk_handlePublicKeyObject (session=<optimized out>, key_type=3, object=0x6b4fa0) at pkcs11.c:970
#2  sftk_handleKeyObject (object=0x6b4fa0, session=0x693170) at pkcs11.c:1397
#3  sftk_handleObject (object=object@entry=0x6b4fa0, session=session@entry=0x693170) at pkcs11.c:1662
#4  0x00007ffff572ece0 in NSC_CreateObject (hSession=<optimized out>, pTemplate=<optimized out>, ulCount=<optimized out>, phObject=0x7fffffffd098) at pkcs11.c:4296
#5  0x00007ffff768e0e2 in PK11_CreateNewObject (slot=slot@entry=0x6929a0, session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, count=count@entry=7, token=token@entry=0,
    objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:397
#6  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
#7  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
    wincx=<optimized out>) at pk11obj.c:736
#8  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
#9  0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360) at secvfy.c:596
#10 0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
    data=0x6b3700 "\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
    dataSize=64, transformCtx=<optimized out>) at signatures.c:347
#11 0x0000000000443b9a in xmlSecTransformVerifyNodeContent (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710) at transforms.c:1523
#12 0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450, node=<optimized out>) at xmldsig.c:353
#13 0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) at xmlsec.c:1223
#14 0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at xmlsec.c:1058
(gdb) print pubKey->u.ec.ecParams.DEREncoding
$7 = {type = siBuffer, data = 0x6b3d08 "\006\005+\201\004", len = 7}
----

> Fortunately you've provided enough information to get an idea of what is
> going on. EC keys have a der encoded parameter telling it what curve the key
> is associated with (generally a der encoded oid pointing to the specific
> curve). The parameter is in the field u.ec.DerEncodedParams, and usually
> applications get this from the spki in a DER certificate, or a raw spki
> encoded structure. You'll need to map the xml way of identifying the curve
> into the der encoding. NOTE: NSS only supports what's called the 'named
> curve' format of the parameters, so if xml is using raw curve parameters,
> then you'll have to map the raw curve parameters into known named curves.

Aha. It seems that u.ec.ecParams.DEREncoding is already filled,
CKR_DOMAIN_PARAMS_INVALID is returned as EC_FillParams() fails. Here is
where it sets its error:

----
251         if (!params->cofactor) {
(gdb)
252             PORT_SetError(SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE);
(gdb) bt
#0  EC_FillParams (arena=arena@entry=0x6b35c0, encodedParams=encodedParams@entry=0x6b3cf0, params=params@entry=0x6b3c30) at ecdecode.c:252
#1  0x00007ffff572b696 in sftk_GetPubKey (object=object@entry=0x6b4fe0, key_type=key_type@entry=3, crvp=crvp@entry=0x7fffffffced0) at pkcs11.c:1789
#2  0x00007ffff572be7c in sftk_handlePublicKeyObject (session=<optimized out>, key_type=3, object=0x6b4fe0) at pkcs11.c:970
#3  sftk_handleKeyObject (object=0x6b4fe0, session=0x693170) at pkcs11.c:1397
#4  sftk_handleObject (object=object@entry=0x6b4fe0, session=session@entry=0x693170) at pkcs11.c:1662
#5  0x00007ffff572ece0 in NSC_CreateObject (hSession=<optimized out>, pTemplate=<optimized out>, ulCount=<optimized out>, phObject=0x7fffffffd098) at pkcs11.c:4296
#6  0x00007ffff768e0e2 in PK11_CreateNewObject (slot=slot@entry=0x6929a0, session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, count=count@entry=7, token=token@entry=0,
    objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:397
#7  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
#8  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280,
    wincx=<optimized out>) at pk11obj.c:736
#9  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0, hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
#10 0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360) at secvfy.c:596
#11 0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
    data=0x6b3740 "\257\237\003<\221\301\330X\273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\003f_l\031\062Wʼ7\016*ڱ",
    dataSize=64, transformCtx=<optimized out>) at signatures.c:347
#12 0x0000000000443b9a in xmlSecTransformVerifyNodeContent (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710) at transforms.c:1523
#13 0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450, node=<optimized out>) at xmldsig.c:353
#14 0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) at xmlsec.c:1223
#15 0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at xmlsec.c:1058
(gdb) print encodedParams->len
$1 = 7
(gdb) x/7xb encodedParams->data
0x6b3d48:       0x06    0x05    0x2b    0x81    0x04    0x00    0x0a
----

'openssl asn1parse' recognizes the above DER as the 'secp256k1' OID.

I may be wrong, but that looks like a named curve parameter to me.

Does the above mean that this EC type is just not supported by NSS
currently? If so, how hard would it be to add support for this one? Is
this just a matter of adding a new constant to recognize it, or the
situation is more complex?

(This parameter doesn't seem to be too rare, if you search for
"secp256k1" in your browser. :-) )

Thanks,

Miklos

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Franziskus Kiefer
>
> 'openssl asn1parse' recognizes the above DER as the 'secp256k1' OID.


NSS currently doesn't support secp256k1 and there are no plans to implement
it afaik. I know that it's popular in certain circles but as far as I know
those don't often overlap with scenarios in which NSS is used.
That said patches are always welcome ;)

Cheers,
Franziskus

On Wed, Feb 15, 2017 at 9:20 AM, Miklos Vajna <[hidden email]> wrote:

> Hi,
>
> On Tue, Feb 14, 2017 at 09:07:24AM -0800, Robert Relyea <
> [hidden email]> wrote:
> > You would need to install the -debug package for nss-softokn on the
> distro
> > to step into softoken (assuming you aren't using a hardware
> accellerator).
>
> Thanks, I didn't realize there are multiple -debuginfo packages for the
> same -debugsource ones.
>
> So here is exactly how CKR_DOMAIN_PARAMS_INVALID is set:
>
> ----
> (gdb) next
> 1789                if (EC_FillParams(arena, &pubKey->u.ec.ecParams.
> DEREncoding,
> (gdb) next
> 1791                    crv = CKR_DOMAIN_PARAMS_INVALID;
> (gdb)
> 1789                if (EC_FillParams(arena, &pubKey->u.ec.ecParams.
> DEREncoding,
> (gdb) print crv
> $5 = 0
> (gdb) next
> 1841        *crvp = crv;
> (gdb) print crv
> $6 = 304
> (gdb) bt
> #0  sftk_GetPubKey (object=object@entry=0x6b4fa0, key_type=key_type@entry=3,
> crvp=crvp@entry=0x7fffffffced0) at pkcs11.c:1841
> #1  0x00007ffff572be7c in sftk_handlePublicKeyObject (session=<optimized
> out>, key_type=3, object=0x6b4fa0) at pkcs11.c:970
> #2  sftk_handleKeyObject (object=0x6b4fa0, session=0x693170) at
> pkcs11.c:1397
> #3  sftk_handleObject (object=object@entry=0x6b4fa0, session=session@entry
> =0x693170) at pkcs11.c:1662
> #4  0x00007ffff572ece0 in NSC_CreateObject (hSession=<optimized out>,
> pTemplate=<optimized out>, ulCount=<optimized out>,
> phObject=0x7fffffffd098) at pkcs11.c:4296
> #5  0x00007ffff768e0e2 in PK11_CreateNewObject (slot=slot@entry=0x6929a0,
> session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0,
> count=count@entry=7, token=token@entry=0,
>     objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:397
> #6  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0,
> pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
> #7  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0,
> mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0,
> hash=hash@entry=0x7fffffffd280,
>     wincx=<optimized out>) at pk11obj.c:736
> #8  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0,
> hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
> #9  0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360)
> at secvfy.c:596
> #10 0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
>     data=0x6b3700 "\257\237\003<\221\301\330X\
> 273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\
> 246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\
> 003f_l\031\062Wʼ7\016*ڱ",
>     dataSize=64, transformCtx=<optimized out>) at signatures.c:347
> #11 0x0000000000443b9a in xmlSecTransformVerifyNodeContent
> (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710)
> at transforms.c:1523
> #12 0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450,
> node=<optimized out>) at xmldsig.c:353
> #13 0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>)
> at xmlsec.c:1223
> #14 0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at
> xmlsec.c:1058
> (gdb) print pubKey->u.ec.ecParams.DEREncoding
> $7 = {type = siBuffer, data = 0x6b3d08 "\006\005+\201\004", len = 7}
> ----
>
> > Fortunately you've provided enough information to get an idea of what is
> > going on. EC keys have a der encoded parameter telling it what curve the
> key
> > is associated with (generally a der encoded oid pointing to the specific
> > curve). The parameter is in the field u.ec.DerEncodedParams, and usually
> > applications get this from the spki in a DER certificate, or a raw spki
> > encoded structure. You'll need to map the xml way of identifying the
> curve
> > into the der encoding. NOTE: NSS only supports what's called the 'named
> > curve' format of the parameters, so if xml is using raw curve parameters,
> > then you'll have to map the raw curve parameters into known named curves.
>
> Aha. It seems that u.ec.ecParams.DEREncoding is already filled,
> CKR_DOMAIN_PARAMS_INVALID is returned as EC_FillParams() fails. Here is
> where it sets its error:
>
> ----
> 251         if (!params->cofactor) {
> (gdb)
> 252             PORT_SetError(SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE);
> (gdb) bt
> #0  EC_FillParams (arena=arena@entry=0x6b35c0,
> encodedParams=encodedParams@entry=0x6b3cf0, params=params@entry=0x6b3c30)
> at ecdecode.c:252
> #1  0x00007ffff572b696 in sftk_GetPubKey (object=object@entry=0x6b4fe0,
> key_type=key_type@entry=3, crvp=crvp@entry=0x7fffffffced0) at
> pkcs11.c:1789
> #2  0x00007ffff572be7c in sftk_handlePublicKeyObject (session=<optimized
> out>, key_type=3, object=0x6b4fe0) at pkcs11.c:970
> #3  sftk_handleKeyObject (object=0x6b4fe0, session=0x693170) at
> pkcs11.c:1397
> #4  sftk_handleObject (object=object@entry=0x6b4fe0, session=session@entry
> =0x693170) at pkcs11.c:1662
> #5  0x00007ffff572ece0 in NSC_CreateObject (hSession=<optimized out>,
> pTemplate=<optimized out>, ulCount=<optimized out>,
> phObject=0x7fffffffd098) at pkcs11.c:4296
> #6  0x00007ffff768e0e2 in PK11_CreateNewObject (slot=slot@entry=0x6929a0,
> session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0,
> count=count@entry=7, token=token@entry=0,
>     objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:397
> #7  0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0,
> pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232
> #8  0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0,
> mechanism=<optimized out>, param=param@entry=0x0, sig=sig@entry=0x7fffffffd2a0,
> hash=hash@entry=0x7fffffffd280,
>     wincx=<optimized out>) at pk11obj.c:736
> #9  0x00007ffff768e99e in PK11_Verify (key=<optimized out>, sig=sig@entry=0x7fffffffd2a0,
> hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690
> #10 0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, sig=sig@entry=0x7fffffffd360)
> at secvfy.c:596
> #11 0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0,
>     data=0x6b3740 "\257\237\003<\221\301\330X\
> 273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\
> 246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\
> 003f_l\031\062Wʼ7\016*ڱ",
>     dataSize=64, transformCtx=<optimized out>) at signatures.c:347
> #12 0x0000000000443b9a in xmlSecTransformVerifyNodeContent
> (transform=0x6ab4d0, node=<optimized out>, transformCtx=transformCtx@entry=0x7fffffffd710)
> at transforms.c:1523
> #13 0x000000000044e0f4 in xmlSecDSigCtxVerify (dsigCtx=dsigCtx@entry=0x7fffffffd450,
> node=<optimized out>) at xmldsig.c:353
> #14 0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>)
> at xmlsec.c:1223
> #15 0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at
> xmlsec.c:1058
> (gdb) print encodedParams->len
> $1 = 7
> (gdb) x/7xb encodedParams->data
> 0x6b3d48:       0x06    0x05    0x2b    0x81    0x04    0x00    0x0a
> ----
>
> 'openssl asn1parse' recognizes the above DER as the 'secp256k1' OID.
>
> I may be wrong, but that looks like a named curve parameter to me.
>
> Does the above mean that this EC type is just not supported by NSS
> currently? If so, how hard would it be to add support for this one? Is
> this just a matter of adding a new constant to recognize it, or the
> situation is more complex?
>
> (This parameter doesn't seem to be too rare, if you search for
> "secp256k1" in your browser. :-) )
>
> Thanks,
>
> Miklos
>
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Martin Thomson
On Wed, Feb 15, 2017 at 7:37 PM, Franziskus Kiefer <[hidden email]> wrote:
> NSS currently doesn't support secp256k1 and there are no plans to implement
> it afaik. I know that it's popular in certain circles but as far as I know
> those don't often overlap with scenarios in which NSS is used.
> That said patches are always welcome ;)

Let's just say that this is a feature that is frequently requested.
Searching bugzilla.m.o you will probably find a bug regarding this
curve that makes for entertaining reading.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Miklos Vajna
Hi,

On Wed, Feb 15, 2017 at 07:52:48PM +1100, Martin Thomson <[hidden email]> wrote:
> Let's just say that this is a feature that is frequently requested.
> Searching bugzilla.m.o you will probably find a bug regarding this
> curve that makes for entertaining reading.

Ah, I see. I had no intention to choose secp256k1 in particular, it's
just that xmlsec's ECDSA-SHA256 testcase uses it.

To avoid solving multiple problems at once, probably I'll go for an
other ECDSA testcase first where the parameter is supported by NSS. :-)

Regards,

Miklos

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Martin Thomson
On Wed, Feb 15, 2017 at 7:59 PM, Miklos Vajna <[hidden email]> wrote:
> To avoid solving multiple problems at once, probably I'll go for an
> other ECDSA testcase first where the parameter is supported by NSS. :-)

The best supported curve is P-256 (i.e., secp256r1), but P-384
(secp384r1) and P-521 (secp521r1) are also well supported.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Gervase Markham
In reply to this post by Miklos Vajna
On 15/02/17 10:23, Martin Thomson wrote:
> The best supported curve is P-256 (i.e., secp256r1), but P-384
> (secp384r1) and P-521 (secp521r1) are also well supported.

There seemed to be some confusion recently in m.d.s.policy about whether
NSS, and then Firefox, supported P-521 for server auth certs. Can
someeone clear it up for me and tell me what the situation is? :-)

Gerv
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Martin Thomson
On Thu, Feb 16, 2017 at 3:44 AM, Gervase Markham <[hidden email]> wrote:
> There seemed to be some confusion recently in m.d.s.policy about whether
> NSS, and then Firefox, supported P-521 for server auth certs. Can
> someeone clear it up for me and tell me what the situation is? :-)

Sure.  Both NSS and Firefox support P-521.  We still accept TLS
handshakes that use it (for both key exchange and signing).  I believe
that it is also supported in webcrypto.

I believe that Chrome doesn't support P-521 in TLS.  We tried to
follow them, but only briefly.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Gervase Markham
In reply to this post by Gervase Markham
On 15/02/17 17:17, Martin Thomson wrote:
> Sure.  Both NSS and Firefox support P-521.  We still accept TLS
> handshakes that use it (for both key exchange and signing).  I believe
> that it is also supported in webcrypto.
>
> I believe that Chrome doesn't support P-521 in TLS.  We tried to
> follow them, but only briefly.

Did things break when we disabled it?

Do we know why Chrome decided not to support it? Two NIST curves is enough?

Gerv
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Martin Thomson
On Thu, Feb 16, 2017 at 4:22 AM, Gervase Markham <[hidden email]> wrote:
> Did things break when we disabled it?

A few things.  It lasted less than a day in Nightly before we got
multiple bug reports.

> Do we know why Chrome decided not to support it? Two NIST curves is enough?

That's my understanding.  P-521 isn't busted, it's just a little
inefficient and not enough stronger than P-384 (or X448) that it is
worth keeping around when faced with a working quantum computer.  That
and the fact that more options is more code to carry, more options to
signal, and so forth.  I think that's the reasoning.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: xmlsec / ECDSA problem

Jeremy Rowley
It's still permitted in the policy.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs
/policy/#inclusion

Section 8.

-----Original Message-----
From: dev-tech-crypto
[mailto:dev-tech-crypto-bounces+jeremy.rowley=[hidden email]
] On Behalf Of Martin Thomson
Sent: Wednesday, February 15, 2017 5:06 PM
To: mozilla's crypto code discussion list
<[hidden email]>
Cc: mozilla-dev-tech-crypto <[hidden email]>
Subject: Re: xmlsec / ECDSA problem

On Thu, Feb 16, 2017 at 4:22 AM, Gervase Markham <[hidden email]> wrote:
> Did things break when we disabled it?

A few things.  It lasted less than a day in Nightly before we got multiple
bug reports.

> Do we know why Chrome decided not to support it? Two NIST curves is
enough?

That's my understanding.  P-521 isn't busted, it's just a little inefficient
and not enough stronger than P-384 (or X448) that it is worth keeping around
when faced with a working quantum computer.  That and the fact that more
options is more code to carry, more options to signal, and so forth.  I
think that's the reasoning.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Martin Thomson
On Sat, Feb 18, 2017 at 8:59 AM, Jeremy Rowley
<[hidden email]> wrote:
> It's still permitted in the policy.
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs
> /policy/#inclusion

Yes, well...  The policy says P-512, which doesn't actually exist.
The intent is clear though.  I've asked Kathleen to correct that.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: xmlsec / ECDSA problem

Peter Bowen
In reply to this post by Gervase Markham
On Wed, Feb 15, 2017 at 9:22 AM, Gervase Markham <[hidden email]> wrote:

> On 15/02/17 17:17, Martin Thomson wrote:
>> Sure.  Both NSS and Firefox support P-521.  We still accept TLS
>> handshakes that use it (for both key exchange and signing).  I believe
>> that it is also supported in webcrypto.
>>
>> I believe that Chrome doesn't support P-521 in TLS.  We tried to
>> follow them, but only briefly.
>
> Did things break when we disabled it?
>
> Do we know why Chrome decided not to support it? Two NIST curves is enough?

I don't have any knowledge of why Chrome decided to only support P-256
and P-384.

I do know that P-256 and P-384 were the only two curves included in
the US NSA's "Suite B" specification and that the NSA did offer an
Elliptic Curve Cryptography (ECC) Patent License Agreement (PLA)
[http://web.archive.org/web/20130308064650/http://www.nsa.gov/business/programs/quick_facts.shtml]
at no charge for certain products.

It is possible that an implementer of Elliptic Curve cryptography
might want have decided to only implement curves included
specifications that are presumably covered by no charge patent license
agreements.

Thanks,
Peter
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Loading...