Hello.
I need a little help with mbedtls 2.16.3.
I'm using it under x86-64 with asio-standalone.
Here's a standard situation:
- I call mbedtls_ssl_write() to write let's say 8192 bytes of payload
- it calls my own bio_send() with (8192+21) bytes as len parameter
- bio_send() returns len=(8192+21), indicating transport data correctly
written
- mbedtls_ssl_write() returns 8192, indicating payload send
GOOD: next I use this value to shift application buffer (erase first
8192 bytes), then send next chunk
BUT after some time of running this situation happens:
- once again, a call to mbedtls_ssl_write() to write let's say 8192
bytes of payload
- it calls bio_send() with smaller number, about 5500 bytes as len
parameter (?? but OK)
- bio_send() returns len=5500, indicating transport data correctly written
- mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating
payload send
BAD: next I use this value to shift application buffer (erase first 8192
bytes), this leads to data loss of (8192-5500)=2692 bytes and ruins protocol
As you can see, mbedtls_ssl_write() incorrectly reports about sent
application data (8192 instead of 5500) - is this a bug? How can such
situation happen under normal operation?
Thanks in advance.
Hi Farhad,
Mbed TLS currently supports hardware acceleration through alternative
implementations of the corresponding modules or functions. See
https://tls.mbed.org/kb/development/hw_acc_guidelines . This mechanism
is available for symmetric cryptography and partially for RSA and ECC.
There is some work in progress on a new mechanism for hardware
acceleration through the psa_xxx() API, which will be available for all
algorithms. You can follow the work in progress on the “Unified driver
interface: API design and prototype” epic at
https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 .
Hope this helps,
--
Gilles Peskine
Mbed TLS developer
On 04/12/2020 11:20, saghili via mbed-tls wrote:
> Dear Sir/Madam,
>
> Our platform is a quad core Cortex A53 running PetaLinux.
> In our hardware, "AF_ALG" module has performance accelerations
> available through the Linux crypto drivers.
> Is it possible that we have "AF_ALG" for offloading crypto operations?
>
> Best regards,
> Farhad
Dear Sir/Madam,
Our platform is a quad core Cortex A53 running PetaLinux.
In our hardware, "AF_ALG" module has performance accelerations available
through the Linux crypto drivers.
Is it possible that we have "AF_ALG" for offloading crypto operations?
Best regards,
Farhad
Hello, I am using ESP32 Dev Module, which supports MbedTLS. I have two
questions, but I can't find the answer on the forum:
1.Is there any way to import RSA keys from string(ideally from PEM format)
to mbedtls_pk context?
2.How to encrypt with RSA private key and decrypt with RSA public key?
Thanks
Radim Kohout
Thanks Gilles. I have use mbedtls_ecdsa_sign and got the raw buffer output
of R & S values.
On Sun, Nov 22, 2020, 9:26 PM Gilles Peskine via mbed-tls <
mbed-tls(a)lists.trustedfirmware.org> wrote:
> 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
> >
>
>
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
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
>