Thank you for quick response.
> Are you using blocking or non-blocking I/O?
Non-blocking IO
I've preset bio_send/recv callbacks
I have pair of buffers, transport buffer and application buffer, for
reading and writing (4 buffers total). Application buffers are protected
by mutexes.
Transport buffers are written/read in bio_send/recv (if no async op
pending, otherwise WANT_READ/WRITE).
mbedtls_ssl_xxx work with application buffers.
> Are you using TLS or DTLS? What protocol version, what cipher suite
and what extensions are negotiated?
TLS (over tcp, no lossy channel involved)
version 1.2
> Does your application call mbedtls_ssl_write() and mbedtls_ssl_read()
again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or
MBEDTLS_ERR_SSL_WANT_WRITE?
Well, actually, no. AND it's quite possible, that application outgoing
buffer (std::vector) has been relocated between mbedtls_ssl_write calls,
because app could push data several times while async op was pending and
bio_send returned WANT_WRITE, causing these buffers to resize. So
buf.data() will not be equal to that from previous mbedtls_ssl_write
call. Is this what causes trouble? It's somehow connected to partial
sends? I do call ssl_write inside while-loop, counting sent and unsent
bytes - thought this was enough. But if mbedtls somehow remembers
addresses from previos calls - that might cause problems.
> Do you close the TLS connection if mbedtls_ssl_xxx() returns an error
other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)?
Yes, but that never happens (from handshake to until problem appears)
> What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or
MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)?
Not defined in config, looks like both 16834
>What operating system are you using?
Ubuntu 20, Kali 20
> Is this a client or a server? What TLS stack does the other side run?
Both are written same way, both using same library.
I'll try to prepare test-case code, that reproduces the problem, and
logs, but that will require some time.
10.12.2020 1:07, Gilles Peskine via mbed-tls пишет:
> Hi Андрей,
>
> The behavior you describe is a bug. But there isn't enough information
> to tell whether the bug is in Mbed TLS, in asio-standalone, in some
> other third-party code, or in your application.
>
> Some things to consider:
>
> * Are you using blocking or non-blocking I/O?
> * Are you using TLS or DTLS? What protocol version, what cipher suite
> and what extensions are negotiated?
> * Does your application call mbedtls_ssl_write() and mbedtls_ssl_read()
> again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or
> MBEDTLS_ERR_SSL_WANT_WRITE?
> * Do you close the TLS connection if mbedtls_ssl_xxx() returns an error
> other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)?
> * What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or
> MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)?
> * What operating system are you using?
> * Is this a client or a server? What TLS stack does the other side run?
>
> You'll give others the most chance to help you if you post small,
> complete code to reproduce the problem. I realize this may be difficult.
> A good intermediate way to see what is going on would be to post debug
> logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and
> call these functions before opening the TLS connection:
>
> mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout);
> mbedtls_debug_set_threshold(2);
>
> See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version
> of my_debug().
>
> Calls to bio_send() are shown in the logs as
>
> => flush output
> message length: %d, out_left: %d
> ssl->f_send() returned %d
> <= flush output
>
> If they don't show expected numbers, the rest of the logs should give a
> clue as to why.
>
> Hope this helps,
>
By the way, I notice you're using Mbed TLS 2.16.3. This version has
known bugs, including security issues. Please upgrade to the latest Mbed
TLS 2.16.x (currently 2.16.8, very soon 2.16.9) which is a security and
bugfix update, or to the latest release (2.24.0, soon 2.25.0) which has
all the latest bugfixes and features. Looking at the changelog, I don't
see any mention of a bug that could explain your problem, but I might
have missed something.
--
Gilles Peskine
Mbed TLS developer
On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote:
> 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 Андрей,
The behavior you describe is a bug. But there isn't enough information
to tell whether the bug is in Mbed TLS, in asio-standalone, in some
other third-party code, or in your application.
Some things to consider:
* Are you using blocking or non-blocking I/O?
* Are you using TLS or DTLS? What protocol version, what cipher suite
and what extensions are negotiated?
* Does your application call mbedtls_ssl_write() and mbedtls_ssl_read()
again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or
MBEDTLS_ERR_SSL_WANT_WRITE?
* Do you close the TLS connection if mbedtls_ssl_xxx() returns an error
other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)?
* What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or
MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)?
* What operating system are you using?
* Is this a client or a server? What TLS stack does the other side run?
You'll give others the most chance to help you if you post small,
complete code to reproduce the problem. I realize this may be difficult.
A good intermediate way to see what is going on would be to post debug
logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and
call these functions before opening the TLS connection:
mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout);
mbedtls_debug_set_threshold(2);
See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version
of my_debug().
Calls to bio_send() are shown in the logs as
=> flush output
message length: %d, out_left: %d
ssl->f_send() returned %d
<= flush output
If they don't show expected numbers, the rest of the logs should give a
clue as to why.
Hope this helps,
--
Gilles Peskine
Mbed TLS developer
On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote:
> 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.
>
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
>