Hi all,
I'm using an mbedTLS server on a CPU with a small memory foot print. In a search to serve as many as possible TLS clients, I found that the mbedtls_ssl_session.master[48] structure member is still in memory after the handshake is over.
(I filed an issue to start with, but was quickly directed to this mailing list, thanks to Tom Cosgrove. See Clear master secret from mbedtls_ssl_session after handshake is ready * Issue #5832 * Mbed-TLS/mbedtls (github.com)<https://github.com/Mbed-TLS/mbedtls/issues/5832>)
I'm wondering why this is needed. The `master` secret references I can find in the code are either related to the TLS handshake, or to serialization/deserialization. I am wondering whether it makes sense to serialize/deserialize the master secret but I'm not sure if it is a use case to support serialization of ongoing handshake operations.
Based on this 2 questions:
* Is the master secret relevant when the handshake is over?
* Is the master secret really useful in serialization/deserialization? If so, I could use `MBEDTLS_SSL_CONTEXT_SERIALIZATION` in my eventual merge request to keep facilitating this.
Looking forward for relevant answers. Thanks in advance,
Maarten
You have been invited to the following event.
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 2am to 2:50am on Monday 20 times Mountain Standard
Time - Phoenix
Calendar: mbed-tls(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* nnac123(a)gmail.com
* santosdanillo(a)gmail.com
* schoenle.thomas(a)googlemail.com
* psa-crypto(a)lists.trustedfirmware.org
* mbed-tls(a)lists.trustedfirmware.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=MzE1cHJuZGxwMDFo…
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 organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi All,
A gentle reminder that the next MBed TLS Tech forum is next Monday at
4:30pm UK time.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi,
I am using mbedTLS v3.0.0 on a low performance CPU on a non-threaded environment, a custom task manager, which is not a preemptive operating system.
I have been using MBEDTLS_ECP_RESTARTABLE so even the long ECC calculations during the handshake periodically returned so the external logic and task manager could run without being blocked for too long.
Recently an IoT SAFE implementation was introduced through PSA API. It is used for RNG and verification calculation, but not for ECDSA and ECDH during key exchange.
PSA API is designed for threaded environments and can not simultaneously use MBEDTLS_ECP_RESTARTABLE. Now the ECC functions block for several seconds.
Do you have a recommendation on how to use PSA on non-threaded environments, or how to inject external logic execution during these long ECC operations?
Thanks,
Gergely
Hi,
I am using mbedTLS v3.0.0 on a low performance CPU on a non-threaded
environment, a custom task manager, which is not a preemptive operating
system.
I have been using MBEDTLS_ECP_RESTARTABLE so even the long ECC calculations
during the handshake periodically returned so the external logic and task
manager could run without being blocked for too long.
Recently an IoT SAFE implementation was introduced through PSA API. It is
used for RNG and verification calculation, but not for ECDSA and ECDH
during key exchange.
PSA API is designed for threaded environments and can not simultaneously
use MBEDTLS_ECP_RESTARTABLE. Now the ECC functions block for several
seconds.
Do you have a recommendation on how to use PSA on non-threaded
environments, or how to inject external logic execution during these long
ECC operations?
Thanks,
Gergely
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.
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
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
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
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));
}
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
***************************************
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
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?
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.
I am trying to modify the dtls_server.c example to keep track of whether session caching was used for a given connection.
Ideally I would have an interget value i.e `session_resumed = #1 or 0`
One way I tried to do this was by reading the value of the mbedtls_ssl_context struct `ssl`:
```
/*
* 5. Handshake
*/
do ret = mbedtls_ssl_handshake( &ssl );
while( ret == MBEDTLS_ERR_SSL_WANT_READ || ret == MBEDTLS_ERR_SSL_WANT_WRITE );
if( ret == MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED ) {
printf( " hello verification requested\n" );
ret = 0;
goto reset;
}
else if( ret != 0 ) {
printf( " failed\n ! mbedtls_ssl_handshake returned -0x%x\n\n", (unsigned int) -ret );
goto reset;
}
printf( " session cache status: %d\n", ssl.handshake.resume );
```
The issue with this is that the ssl struct is set to private, so the code fails to compile with the error: 'struct mbedtls_ssl_context' has no member named 'handshake'
Can somebody help me with some example code that would make this possible?
Hi all,
Please note that in the next couple of weeks, we will migrate Mbed TLS to a new GitHub organisation. Your existing scripts, links etc for accessing Mbed TLS on GitHub should not be affected.
This will change the url from https://github.com/ARMmbed/mbedtls to https://github.com/Mbed-TLS/mbedtls . GitHub will redirect any accesses to the old URL for the foreseeable future, but we would recommend updating your links once the migration is complete.
All of the Mbed TLS repositories will migrate to this new organisation, i.e.:
mbedtls
mbedtls-docs
mbedtls-test
Thanks
Dave Rodgman
Hello,
mbedTLS has ECDSA module that takes Signature with ASN1 encoding as input
mbedtls_pk_verify()
The Signature I receive is without ASN1 encoded.
Trying to find an implementation within mbedTLS that can add ASN1 to signature before I feed into the verify function.
Any help ?
[RF IDeas]<http://www.rfideas.com/>
Deep Patel
Sr. Embedded Software Engineer
D:
224-333-2084
P:
847-870-1723 Ext 437
E:
ddpatel(a)rfideas.com<mailto:ddpatel@rfideas.com>
A: <https://www.rfideas.com/>
425 North Martingale Road, Suite 1680, Schaumburg, IL 60173
<https://www.rfideas.com/>
Hi All,
Please find the link to the TrustedFirmware Community Code of Conduct here:
https://developer.trustedfirmware.org/w/collaboration/community_guidelines/…
Trusted Firmware has a very diverse and global developer community. It is
important that we adhere to the code of conduct in all our interactions.
For some of you all this may be new and for others just a gentle reminder.
In either case, if you have any questions, please feel free to reach out to
me directly.
And thanks to you all for your contributions to the TrustedFirmware
community!
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello!
Is there a time plan for when there will be an official release with TLS 1.3 (Client) that supports mutual authentication?
Kind Regards
Tove Rumar
Software Engineer
u-blox Malmo
Östra Varvsgatan 4
SE- Malmö
www.u-blox.com<https://www.u-blox.com>
Reliable. Smart. Secure.
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello,
we are using mbedTLS version 2.16.
We are facing a problem in verifying the signed message for ECDSA type of
algorithms. Do you have any sample code for this as given for the RSA type
algorithm in rsa_verify.c.
We have derived the R and S values and their length, but we are not sure
which context to use to verify the signature.
Please help urgently.
--
Regards,
Sunil Jain
Hi thanks for getting back to me,
That's fine if it doesn't work in future releases, I will most likely stay
on 3.0.0.
Unfortunately when trying to add this line to the dtls_server example I get:
error: dereferencing pointer to incomplete type
'mbedtls_ssl_handshake_params' {aka 'struct mbedtls_ssl_handshake_params'}
int resumed = ssl.MBEDTLS_PRIVATE(handshake)->resume;
^~
my use case for this is to test a client's ability to connect to the server
and use session caching, I want to essentially send messages to the server
from a client, and have the server send a message back either 'session
cache was used' or 'session cache was not used'.
Good afternoon, I'm trying to implement TLS 1.2. for MMS using the library libiec61850. When a connection is established, the interaction is interrupted at the stage "Client Key Exchange".
Also, when monitoring the interaction through wireshark, I see that an error is displayed at the "Certificate Request" stage. I use default certificates, the project is built through CMake on Windows and TLS 1.1. works flawlessly. In the file tls_mbedtls.c I changed only the values of the minimum and maximum versions to TLS 1.2.
Thank you in advance for your response.