Hi All,
We are using the MBedTLS 3.6.0 release stack and often see the TLS
client -> server sending Encrypted Alert 21 packets followed by
closing the SSL connection (or rather reconnection starting from new
handshake messages).
As far as I understand Alert 21 is a fatal message stating Decryption
of a TLSCiphertext record is decrypted in an invalid way: either it
was not an even multiple of the block length or its padding values,
when checked, were not correct - copied from the Internet.
But then Handshake and Application Data goes thru fine for a while and
then we see our client sending Alert 21 encrypted message
Is it legitimate that the client can send Alert 21 messages to the
server and close the current connection - we are observing that the
server application is waiting for messages from the client and is
un-aware that a connection reset has occurred. So the server
application states a timeout for receiving messages from the client.
Further, how can we assert such a scenario? When and how can it occur?
Is there a way we can simulate it and send details to owners of server
firmware to fix their issue?
Regards,
Prakash
Hi All,
We are using MbedTLS on our devices and implementing PSA wrappers to use our Crypto hardware.
For validating this one we are using MbedTLS test suites.
Could you please tell me:
1. Does your test suites compliant to FIPS 140-3?
2. Do you use NIST test vectors to validate your algorithm implementations?
Thanks.
Viktor Ivanets.
On a project at my company, we're using mbedtls to encrypt and sign our
data. We began the project with mbedtls 2.2.6, and have continuously
upgraded until now, 3.6.0.
I've noticed my application has grown greatly since then, even though we
are only using the following APIs:
Encryption:(only decryption on the embedded side)
- mbedtls_aes_init
- mbedtls_aes_setkey_dec
- mbedtls_aes_crypt_cbc
Signing (only verification on the embedded side)
- mbedtls_ecp_point_read_binary
- mbedtls_sha256_init/free
- mbedtls_sha256_starts_ret
- mbedtls_sha256_update_ret
- mbedtls_sha256_finish_ret
- mbedtls_ecdsa_init/free
- mbedtls_ecp_group_load
- mbedtls_ecdsa_read_signature
The size of libembedcrypto.a has grown from under 400K to almost 800K.
I've tried reducing it with mbedtls_config,h, but it is not entirely clear
to me which #defines do what. I tried one of the sample configs which by
it;s name looked promising (crypto-config-ccm-aes-sha256.h), and it reduced
the size of the library by 90%, but left me with link errors for all of the
above functions. Going one #define at a time manually to see if it saves
or grows is slow, and so I hoped I could find some assistance here.
Thanks in advance