Excuse me, I replied to your e-mail without note that I'm replying to your address instead of mailing-list address.
Now I'll do some other tests, starting from a blank project.
I can't send a fully compilable FW because my target is an ESP32 with an OPTIGA crypto chip connected,. than it is necessary to have my hardware to run it. But attached I put my mbedtls configuration.
Thank you, Stefano
Il giorno mer 21 apr 2021 alle ore 14:36 Gilles Peskine < gilles.peskine@arm.com> ha scritto:
I adjusted your code to compile and added the missing definitions and declarations, and this version works for me. I've attached my code. Here's the output I get (Mbed TLS , default configuration):
Message: PLUTOxPLUTOxPLUTOxPLUTOxPLUTOxxx Private key: -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDCv5Vq0yRsOKLkkaI0lR32vByL9MB+4O0f+bhVErb8Fd0W1XFhN1897 iAtnV/DeXDygBwYFK4EEACKhZANiAARgYE9uzG+nXYDoydWyDE6wrlgxiRKqm6kg si00tFa0KD//vCemOAoYAmmbtFd9RvE6tNOw+Ze5eRtVvosmvYl5IoWx4Jda+Wv9 ftRXkUk3nRzcAmXnG7bGmgwNC2iC73s= -----END EC PRIVATE KEY-----
Hash: yrmtrgMb4WzvHD5XWwb00yAE13RCi934x2ySjcWup5g= Signature: MGQCMD8pezXqUF6v01b0WQiIUZWuuvxPR1tT15YnN9atogKR2pBPizBYbbhjAIz+ftm78AIwDogKWZVxDk5r6I38oIn0JALO7h8EcTCwjUsulYS5BRl8iyITAC42Xx+HlRPofwbr Public key: -----BEGIN PUBLIC KEY----- MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEYGBPbsxvp12A6MnVsgxOsK5YMYkSqpup ILItNLRWtCg//7wnpjgKGAJpm7RXfUbxOrTTsPmXuXkbVb6LJr2JeSKFseCXWvlr /X7UV5FJN50c3AJl5xu2xpoMDQtogu97 -----END PUBLIC KEY-----
I don't think I can be of any more help unless you post code to reproduce the problem that can be compiled and run a popular platform (preferably Linux) without modifications, and also your library configuration (mbedtls/config.h). Preferably post those on the mailing list, because I personally have limited time and I'm not sure when I'll next be able to take a look.
Best regards,
-- Gilles Peskine Mbed TLS developer
On 21/04/2021 14:14, stefano664 wrote:
I'm sure that the problem isn't here.
- mbedtls_base64_encode is used only to generate human readable data in
this case, and to print it. The chain have the same behaviour without these.
- I changed len_b64 and olen type to size_t and removed casting. I have
the same result and verify fails...
Here the new code: https://wtools.io/paste-code/b4Hy
Here the new output: https://wtools.io/paste-code/b4H0
Do you have some other idea? Thanks a lot for your help!
Stefano
Il giorno mer 21 apr 2021 alle ore 13:36 Gilles Peskine < gilles.peskine@arm.com> ha scritto:
Ok, I found the problem:
mbedtls_base64_encode(hash_b64, sizeof(hash_b64), (size_t *) &len_b64, hash, 32);
&len_b64 is a pointer to uint16_t. Casting the pointer to size_t* doesn't give you a pointer to a size_t object, it gives you an invalid pointer since it isn't pointing to a size_t object. When mbedtls_base64_encode writes through that pointer, it overwrites whatever is next on the stack. Other calls with a size_t* cast have the same problem. Depending on exactly how your compiler lays out the stack, this might part of the message, or part of the pk structure, or part of the result...
I found this problem because I massaged your code until it ran on Linux, and it crashed during mbedtls_pk_sign because the pk structure had been corrupted. Other potential ways to find such problems include static analysis (Coverity is good but very expensive), AddressSanitizer (if you can build your code on a platform that has enough space), and of course code review (any cast is suspicious: most of the times, when a compiler complains about something, a cast will silence the compiler but not actually fix the problem).
Best regards,
-- Gilles Peskine Mbed TLS developer
On 21/04/2021 09:43, stefano664 wrote:
Hi Gilles, thanks for your reply.
The posted code is without error checks to be smaller. The complete code is here:
https://wtools.io/paste-code/b4Hi
All error checks pass true than all functions seems ok.
In this version I added also the verify, that fail.
Here you can find the output with all prints, messages and datas:
https://wtools.io/paste-code/b4Hj
As you can see my signature is 71 byte wide, a bit too little even after zeroes removing. The same made with openSSL is 104 byte wide. I've checked my keys, and I confirm it is 384 bit. You can check, it is printed during process.
Thanks a lot for your help!
Best regards, Stefano
Il giorno mar 20 apr 2021 alle ore 21:48 Gilles Peskine via mbed-tls < mbed-tls@lists.trustedfirmware.org> ha scritto:
Hi Stefano,
Assuming that the key is in PEM format and that the buffers (hash, tmp) are large enough, I don't see anything wrong in the part of the code you posted.
You posted code without error checking. Can you confirm that all functions return 0?
mbedtls_pk_sign produces ECDSA signatures in ASN.1 format. The size of the signature can be up to 104 bytes, and is often a few bytes shorter because it consists of numbers in which leading zeros are omitted. Make sure the tmp buffer is large enough. You can use MBEDTLS_ECDSA_MAX_SIG_LEN(384) or MBEDTLS_ECDSA_MAX_LEN (from mbedtls/ecdsa.h) as the signature buffer size.
72 bytes is the maximum size of a signature for a 256-bit key, reached about 25% of the time. Are you sure you're signing with the key you intended?
People may be able to help more if you post complete code that we can run on our machine.
Best regards,
-- Gilles Peskine Mbed TLS developer
On 20/04/2021 16:49, stefano664 via mbed-tls wrote:
Hi all, I have some problems with mbedTLS during ECDSA signing process.
I followed the example supplied with the source code and write this
code:
mbedtls_pk_init(&pk); mbedtls_pk_parse_key(&pk, (const unsigned char *) flash.flash_ver0.ecc_priv_key, strlen(flash.flash_ver0.ecc_priv_key) + 1, (const unsigned char *)CA_DEF_ISSUER_PWD, CA_DEF_ISSUER_PWD_LEN); mbedtls_md(mbedtls_md_info_from_type(MBEDTLS_MD_SHA256), msg, msg_len, hash); mbedtls_pk_sign(&pk, MBEDTLS_MD_SHA256, hash, 0, tmp, (size_t *)&len, mbedtls_ctr_drbg_random, &ctr_drbg);
The private key is an ECC key with 384 bit. I have two issue:
- In tmp variable I found the signature, but it is 72 byte, instead
of 96 (384*2/87); 2) On this signature I try to make a verify, but fails.
Where I'm wrong?
Best regards, Stefano
-- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
mbed-tls@lists.trustedfirmware.org