Hi Roshini,
Mathematically, an ES256 (ECDSA over the curve P256R1) signature is a
pair of numbers (r,s) between 1 and an upper bound which is very
slightly less than 2^256. There are two common representations for this
signature. JWA uses the “raw” representation: two big-endian numbers
represented each with exactly 32 bytes, concatenated together.
mbedtls_ecdsa_write_signature uses the ASN.1 DER representation, which
as you noticed represents each number in a type+length+value format.
The DER format removes leading zeros from the number, then adds a
leading 0 bit to each number which is a sign bit (the numbers in an
ECDSA signature are always positive, but DER can also represent negative
numbers). Therefore each number has a roughly 1/2 chance of using 33
value bytes with a leading 0 byte (1 sign bit + 7 value bits, all 0), a
63/128 chance of using 32 value bytes, and a 1/128 chance of using 31
value bytes or less because the 7 most significant bits of the number
were 0. A shorter number in an ECDSA signature is not invalid, it's a
1/128 chance (independently for each of r and s).
To get the signature in raw format with Mbed TLS, the easiest way is to
use the PSA API, where the output of psa_sign_hash() for ECDSA is the
raw format. With the classic Mbed TLS API, the easiest way is to call
mbedtls_ecdsa_sign() or mbedtls_ecdsa_sign_det_ext() to get r and s as
bignums, then use mbedtls_mpi_write_binary() to write r and s with their
exact size into the output buffer. You can find an example in the
internal function psa_ecdsa_sign():
https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/library/psa_crypto.c…
Hope this helps,
--
Gilles Peskine
Mbed TLS developer
On 22/11/2020 10:12, ROSHINI DEVI via mbed-tls wrote:
> Hello all,
>
> I need to sign the message using ES256 algorithm. After doing
> necessary initializations, I called API
> - mbedtls_ecdsa_write_signature() API and it gave me signature in ASN1
> encoded form and there was no error generated by this API.
> After getting the signature, I need the r & s values to create JWT
> Token. So, I wrote my custom function to parse the signature buffer
> and get the R & S values of it.
> It was working fine. Sometimes, I am getting an invalid signature as
> shown below signature DER buffer -
>
> 30 43 02 1f 31 92 8d 22 10 41 86 25 68 7f 42 81 26 0f 37 bc 7f 38 b7
> d5 1a 6b 69 31 07 34 11 a6 04 e5 90 02 20 23 26 f8 b9 80 cf 2c 25 c8
> 04 b4 ac 43 51 6a 04 a6 af 8f 94 36 f8 cf 35 c2 94 cc df de db 92 b2
>
> The reason for invalid is -
> 1st byte represents ASN1 sequence, followed by length and 3rd byter
> indicates it is an integer.
> Ideally, 4th byte indicates length of r-value, it should have been 32
> or 33 bytes ( in case of padding with 00 ). You can see in the above
> buffer it is 0x1F ( 31 bytes ). It is really weird how it is possible
> to get the signature length of 31 bytes.
>
> It is blocking me for generation of JWT token, where in RFC 7518
> - https://tools.ietf.org/html/rfc7518#page-9 , it says R & S must be
> 32 bytes long. And, the generation is failing.
>
> It is of high priority for me. If anyone can provide your suggestions
> on this issue, it would be really great. Thanks in advance
>
> Thanks,
> Roshini
>
Hello all,
I need to sign the message using ES256 algorithm. After doing
necessary initializations, I called API - mbedtls_ecdsa_write_signature()
API and it gave me signature in ASN1 encoded form and there was no error
generated by this API.
After getting the signature, I need the r & s values to create JWT Token.
So, I wrote my custom function to parse the signature buffer and get the R
& S values of it.
It was working fine. Sometimes, I am getting an invalid signature as shown
below signature DER buffer -
30 43 02 1f 31 92 8d 22 10 41 86 25 68 7f 42 81 26 0f 37 bc 7f 38 b7 d5 1a
6b 69 31 07 34 11 a6 04 e5 90 02 20 23 26 f8 b9 80 cf 2c 25 c8 04 b4 ac 43
51 6a 04 a6 af 8f 94 36 f8 cf 35 c2 94 cc df de db 92 b2
The reason for invalid is -
1st byte represents ASN1 sequence, followed by length and 3rd byter
indicates it is an integer.
Ideally, 4th byte indicates length of r-value, it should have been 32 or 33
bytes ( in case of padding with 00 ). You can see in the above buffer it is
0x1F ( 31 bytes ). It is really weird how it is possible to get the
signature length of 31 bytes.
It is blocking me for generation of JWT token, where in RFC 7518 -
https://tools.ietf.org/html/rfc7518#page-9 , it says R & S must be 32 bytes
long. And, the generation is failing.
It is of high priority for me. If anyone can provide your suggestions on
this issue, it would be really great. Thanks in advance
Thanks,
Roshini
Hi everyone,
I am a Mtech student from Indian Institute of Science, Bangalore(India).
Currently, I am crediting computer security course. As the course project,
the professor has asked us to rewrite Mbedtls using Rust language. The
entire class will work on the single project with each person working on a
single module.
I am having trouble finding information regarding Mbedtls architecture, its
modules and their working. I don't even know all the right resources I need
to work on the project.
It would save a lot of time if someone could point me to the right
resources regarding Mbedtls needed for this project.
Sincerely,
Eikansh Gupta
I forgot to mention that there is a work in progress to add PKCS#7 parsing:
https://github.com/ARMmbed/mbedtls/pull/3431
This is an external contribution so its addition to Mbed TLS depends not
only on us maintainers' review bandwidth, but also on the availability
of the kind contributor.
I'm not familiar with .p7* formats so I don't know whether the support
added by this pull request is sufficient to cover all of those.
--
Gilles Peskine
Mbed TLS developer
On 06/11/2020 13:50, Alvaro Gonzalez via mbed-tls wrote:
>
> Hello mbed-tls mailing list.
>
> �
>
> Does mbed-tls comply PKCS7? Can handle .p7, .p7b and/or .p7a extension
> files?
>
> �
>
> Best Regards.
>
> �
>
>
Hi Nick,
It would be great to have even partial support of PKCS#7 in Mbed TLS and
we would welcome your contribution!
You can find some guidance in CONTRIBUTING.md
(https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md).
Feel free to ask on the mailing list if anything is unclear.
Note that there is a work in progress for adding PKCS#7 parsing:
https://github.com/ARMmbed/mbedtls/pull/3431 . It may help to see what
it does, but also note the review comments that point out some remaining
issues. If you and naynajain work on parsing and generation at the same
time, you'll need to synchronize since both sides will need to create
pkcs7.[hc].
--
Gilles Peskine
Mbed TLS developer
On 10/11/2020 17:28, Nick Child via mbed-tls wrote:
> Hello,
>
> For one of my projects, I had to create a PKCS7 generation/builder. I
> noticed mbedtls currently has no support for PKCS7. After much trial
> and error, I was able to use mbedtls functions to create a PKCS7
> structure for Signed Data. I was wondering if this something that
> might be useful in later versions of mbedtls? The code currently has a
> long way to go until it meets mbedtls coding standards, but I figured
> I would ask if it is even possible and worth the efforts before
> getting into it. I am also a rookie when it comes to open source
> contributions, so I was hoping for some guidance regarding merging
> upstream.
>
> Thanks for your time,
>
> Nick Child
>