- mbed-tls - lists.trustedfirmware.org

"RAW RSA" encoding method for signatures

by THIERRY BINIGUER

Hi all, I can see a "RAW RSA" encoding method for signatures both implemented in mbed TLS and PSA API and I'm wondering about the motivations and rational of this variant. Could you tell more about it, please ? Below details. Thierry It was introduced since 2017 in mbed TLS in this sha1 ID : fdf38030de70b95a77205f17d65591f05e74be08 ("Outsource code for generating PKCS1 v1.5 encoding"). As far as I know, standard does not specifically mention it but RFC 8017 ($9.2) specifies EMSA-PKCS1-v1_5 as a deterministic encoding method (no randomness) with a buffer that is built as an encoded message EM = 0x00 || 0x01 || PS || 0x00 || T, where PS being padding bytes, T being a DER encoding of a digestInfo, where digestInfo contains : - the hash function (so called AlgorithmIdentifier applied on the message) - and the hash value (so called digest H = = Hash(M)) PSA defines the RAW RSA in its API. It is said a signature algorithm, without hashing. In this raw RSA PKCS#1 v1.5, the hash parameter to psa_sign_hash is computed "externally". It is a DER encoding, “ready-to-use" hash, so called raw data in PSA and mbed TLS. In the RSA PKCS#1 v1.5, the hash parameter to psa_sign_hash is H (computed with the hash function as indicated in the standard). mbed TLS implementation manages RAW data in rsa_rsassa_pkcs1_v15_encode(), it copies raw data as they are given and pads accordingly. Even if from a security perspective, this variant does not seem to introduce vulnerabilities, there is no information on the used hash algorithm inside the signature itself, therefore making mandatory for the verifier to know exactly which algorithm is used, and therefore less trivial in term of device interoperability.

3 years, 8 months

2
1
0 0

Cancelled event: MBed TLS Technical Forum - Asia @ (BST) (mbed-tls@lists.trustedfirmware.org)

by Mike Holmes

This event has been cancelled. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: United Kingdom Time Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 21:00 to 21:50 on Monday from Mon 31 Jan to Mon 23 May (AEDT) (mbed-tls@lists.trustedfirmware.org)

by santosdanillo＠gmail.com

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 21:00 to 21:50 on Monday from Mon 31 Jan to Mon 23 May Eastern Australia Time - Sydney (changed) Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Updated invitation: MBed TLS Technical Forum - Asia @ Every 4 weeks from 19:00 to 19:50 on Monday 13 times (AEST) (mbed-tls@lists.trustedfirmware.org)

by santosdanillo＠gmail.com

This event has been changed. Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Every 4 weeks from 19:00 to 19:50 on Monday 13 times Eastern Australia Time - Sydney (changed) Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin- creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmU4dm1iNzJ0dmV1… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 8 months

1
0
0 0

Require cross compilation steps

by Krunal Chauhan

Hi, I need updated mbed TLS library version 3.1.0 I need step/procedure to cross compile mbed TLS library. Best Regards, [Logo]<https://www.slscorp.com/> Krunal Chauhan Senior Engineer Email: krunal.chauhan(a)slscorp.com | www.slscorp.com<http://www.slscorp.com> Plot#32, Zone-D/4, Phase-1, GIDC Estate V.U. Nagar - 388 121, Gujarat, India

3 years, 8 months

1
0
0 0

Re: AES Memory Leak

by Minos Galanakis

Hi Subramanian. Thank you for your report. Would it be possible to provide some further information on how the program is structured? Is the code snippet running in a single thread or a multithreaded application? How often is data transmitted (As to many invocations are we considering for an 8-hour window)? How is that while(1) loop interrupted? Which platform architecture is the program running at? I have been trying to reproduce it by expanding the Valgrind test suite, as to repeat the logic included in the example for UINT_MAX iterations, without success. Minos ________________________________ From: Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 16 March 2022 04:24 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] AES Memory Leak Hi, I have developed a program to send encrypted data continuously. The program is working fine for few hours. After 6 to 8 Hrs, I get returned MBEDTLS_ERR_CIPHER_ALLOC_FAILED -0x6180 Do I need to free the gcm context for every time I send data? What would be the root cause. #define AEAD_KEY_SIZE (32) /**< AEAD Key Size(in bytes). */ #define AEAD_IV_SIZE (12) /**< AEAD IV Size(in bytes). */ #define AEAD_AD_SIZE (16) /**< AEAD AAD Size(in bytes). */ #define AEAD_TAG_SIZE (16) /**< AEAD Tag Size(in bytes). */ #define AEAD_ID_SIZE (4) /**< AEAD Tag Size(in bytes). */ #define MAX_CIPHER_SIZE (2048)/**< AEAD Cipher/Plaintext Segent Size unoperation(in bytes). */ typedef struct { mbedtls_gcm_context CtxAead; /**< aes-gcm 3rd party library context */ uint8_t pu8Key[AEAD_KEY_SIZE]; /**< Key - Randomly Generated */ uint8_t pu8InitVector[AEAD_IV_SIZE]; /**< Randomly Generated */ uint8_t pu8AddData[AEAD_AD_SIZE]; /**< Additional Associated Data - md5sum() */ uint8_t pu8Tag[AEAD_TAG_SIZE]; /**< Hold Digest/Tag of encryped data */ uint8_t pu8Id[AEAD_ID_SIZE]; /**< KeyID is generated */ uint8_t pu8Data[MAX_CIPHER_SIZE]; /**< Buffer to hold plain-text after decipher */ uint8_t pu8Cipher[MAX_CIPHER_SIZE]; /**< Buffer to hold cipher-text after cipher */ uint16_t u16Length; /**< Current length of buffer to encrypt/decrypt */ }S_Aead; int32_t i32Aead_EncryptionCycle(S_Aead *ctx ,uint8_t *pu8AddData, uint16_t u16Length ) { int32_t i32Ret = 0; if(NULL == ctx) { return (NULL_AEAD_CTX); } /* Initilaze GCM Context **/ mbedtls_gcm_init ( &(ctx->CtxAead) ); /*SETTING ADDITIONAL DATA as MD5 of incoming data **/ if( AEAD_AD_SIZE < u16Length ) { return (ERROR_INPUT_BUFFER_TOO_LONG); } memset( ctx->pu8AddData, 0x00, AEAD_AD_SIZE ); i32Ret = mbedtls_md5_ret(pu8AddData, u16Length, ctx->pu8AddData); if (i32Ret) { return (i32Ret); } /* symetric key for testing */ memset( ctx->pu8Key, 0xAB, AEAD_KEY_SIZE ) /* Setting the key */ if( i32Ret = mbedtls_gcm_setkey ( &(ctx->CtxAead), MBEDTLS_CIPHER_ID_AES, ctx->pu8Key, AEAD_KEY_SIZE*OCTETS ) ) { return (i32Ret); } while(1) { /* OS Wait for 1000ms for data to get ready */ if( OS_WaitSingleEventTimed( TX_DATA_BUFFER_READY, WAIT_1000MS ) ) { if( ctx->u16Length == 0 ) { /* No data ready for sending (or) timed-out */; continue; } /* New Initial Vector */ if( i32Ret = i32NewRandomByte( ctx->pu8InitVector, AEAD_IV_SIZE, "AEAD_NEW_IV_GENERATION" ) ) { return(i32Ret); } ctx->u16Length = u16Length; if( i32Ret = mbedtls_gcm_crypt_and_tag( &(ctx->CtxAead), MBEDTLS_GCM_ENCRYPT, ctx->u16Length, ctx->pu8InitVector, AEAD_IV_SIZE, ctx->pu8AddData, AEAD_AD_SIZE, ctx->pu8Data, ctx->pu8Cipher, AEAD_TAG_SIZE, ctx->pu8Tag)) { return(i32Ret); } if( ctx->u16Length == send_data(ctx->pu8Cipher, ctx->u16Length) ) { /* tx success*/ memset( ctx->pu8Data, 0x00, ctx->u16Length ); memset( ctx->pu8Cipher, 0x00, ctx->u16Length ); ctx->u16Length = 0; } } } /* Free GCM Context */ mbedtls_gcm_free( &(ctx->CtxAead) ); /* Reset context memory */ memset(ctx, 0, sizeof(S_Aead)); }

3 years, 9 months

1
0
0 0

Re: mbed-tls Digest, Vol 26, Issue 5

by Christie Su

Hi, Is there anyone who can tell me how to send the question related to MbedTLS? Which forum can I sign in? Thanks, Christie -----Original Message----- From: mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org> Sent: April-25-22 8:00 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: mbed-tls Digest, Vol 26, Issue 5 Send mbed-tls mailing list submissions to mbed-tls(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to mbed-tls-request(a)lists.trustedfirmware.org You can reach the person managing the list at mbed-tls-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mbed-tls digest..." Today's Topics: 1. misc. questions (Frank Bergmann) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Apr 2022 12:47:07 +0200 From: Frank Bergmann <mbedtls(a)tuxad.com> Subject: [mbed-tls] misc. questions To: mbed-tls(a)lists.trustedfirmware.org Message-ID: <20220425104707.GA3579(a)treferpol.tuxad.net> Content-Type: text/plain; charset=us-ascii Hi all, I have some questions. 1) If you have an established TLS connection (mbed TLS 3.x) and while the connection is up the (server-) certificate expires: Will the connection stay up? Or is a new handshake (with valid cert) REQUIRED? 2) Related to question 1: CAN mbed TLS switch to a new cert on an existing TLS connection? (e.g. by doing another handshake from server OR client side) 3) With 3.x some struct members are now "private". Even if you can allow private access by a define it would be better to use a getter. But for ssl context's "state" I am missing this and also for "p_bio" (to access fd). Is there a chance to get this implemented? BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you! kind regards, Frank ------------------------------ Subject: Digest Footer mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org ------------------------------ End of mbed-tls Digest, Vol 26, Issue 5 ***************************************

3 years, 9 months

1
0
0 0

Reminder: MBed TLS Technical Forum - Asia

by don.harbin＠linaro.org

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBest TLS Tech forum is next Monday. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Title: MBed TLS Technical Forum - Asia Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: MBed TLS Technical Forum - Asia Time: Nov 8, 2021 10:00 AM London Every 4 weeks on Mon, 20 occurrence(s) Nov 8, 2021 10:00 AM Dec 6, 2021 10:00 AM Jan 3, 2022 10:00 AM Jan 31, 2022 10:00 AM Feb 28, 2022 10:00 AM Mar 28, 2022 10:00 AM Apr 25, 2022 10:00 AM May 23, 2022 10:00 AM Jun 20, 2022 10:00 AM Jul 18, 2022 10:00 AM Aug 15, 2022 10:00 AM Sep 12, 2022 10:00 AM Oct 10, 2022 10:00 AM Nov 7, 2022 10:00 AM Dec 5, 2022 10:00 AM Jan 2, 2023 10:00 AM Jan 30, 2023 10:00 AM Feb 27, 2023 10:00 AM Mar 27, 2023 10:00 AM Apr 24, 2023 10:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT… Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt When: Mon Apr 25, 2022 2am – 2:50am Mountain Standard Time - Phoenix Who: * Don Harbin - creator * psa-crypto(a)lists.trustedfirmware.org * mbed-tls(a)lists.trustedfirmware.org * nnac123(a)gmail.com * santosdanillo(a)gmail.com * schoenle.thomas(a)googlemail.com

3 years, 9 months

1
0
0 0

Mbed tls handshake returns –x7200

by arman_ilmak＠yahoo.com

Hey friends Im trying to do a secure connection between my stm32 board and server. I wrote the code based on GitHub - eziya/STM32F4_HAL_ETH_MBEDTLS: STM32 mbedTLS library testing (SSL/TLS client) that i found. My board is based on stm32h7 series. And im using google to test my app.(ip 142.250.74.196 port 443) This is the debug section: https://aws1.discourse-cdn.com/standard17/uploads/mbed/original/2X/e/ee636c… How should i solve the problem?

3 years, 9 months

2
2
0 0

Issues with mbedtls_rsa_import_raw + mbedtls_rsa_pkcs1_verify

by m4D

Greetings! I'm having an issue while veryfing signature with imported RSA2048 public key, generated with Win7 CryptoAPI (PUBLICKEYBLOB) into latest mbedtls 2.28.x. The blob contains RSA modulus N (256 bytes) and public exponent E (4 bytes) - I do extract them succesfully, then provide into mbedtls_rsa_import_raw. It all goes smth. like this: u32 errval = mbedtls_rsa_init(ctx, MBEDTLS_RSA_PKCS_V15, 0); // errval == 0 here errval = mbedtls_rsa_import_raw(ctx, n, nlen, 0l, 0, 0l, 0, 0l, 0, e, elen); // errval == 0 here errval = mbedtls_rsa_complete(ctx); // errval == 0 here errval = mbedtls_rsa_check_pubkey(ctx); // errval == 0 here Then i ran: errval = mbedtls_rsa_pkcs1_verify(ctx, 0l, 0l, MBEDTLS_RSA_PUBLIC, MBEDTLS_MD_SHA512, 0, _src, _sign); and get -0x4380 (verify failed) _src - is sha512 hash of data to be verified (64 bytes) _sign - is 256 bytes of signature, provided by win7 cryptoapi P.S. just in case, i did tried messing with endianess in every way for e AND n, it didn't help. I added a little debugging inside library/rsa.cpp, turned out we do call mbedtls_rsa_rsassa_pkcs1_v15_verify, and there is a memcmp between 'encoded' and 'encoded_expected' bufs. 'encoded' is derived from signature (_sign), and 'encoded_expected' is derived from hash (_src) printhex for 'encoded' looks like this: 1a1da83b 14be17a2 c8401d41 1d453909 ... total 16 lines (256 bytes) ... 7fb37ea2 719a5562 aebdb3ed 296e0ed1 but printhex for 'encoded_expected' looks like this: ffff0100 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ... wtf??? padding ??? ... ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 30513000 6009060d 65014886 03020403 40040005 b190b45a a40b354f 32271b34 f022abd3 ... sha512-derived data here, 64 bytes 557abf2b e2cc4e0f 0b77bdfc b45688b0 So, there is no way these two bufs match. I wonded if there is some issue in parsing _sign, or I didn't prepared input data good enough. Any ideas? B.R., m4D.

3 years, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls