Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
When `mbedtls_pk_verify` is used to verify digital signatures generated by openssl, the MBEDTLS_ERR_RSA_VERIFY_FAILED error occurs, openssl Specifies the command used to generate a certificate:
```bash
openssl md5 -sign private.key -out sign test.md
```
But when I use `mbedtls_pk_sign(&pk_pri_ctx, MBEDTLS_MD_MD5, md, 0, sign_info, sizeof(sign_info), &size, mbedtls_ctr_drbg_random, &ctrl_drbg)` Generating the signature and using `mbedtls_pk_verify` results are successful, Print the signatures generated by mbedtls are not found to be the same as those generated by openssl. Please help。
mbedtls version:
```c
#define MBEDTLS_VERSION_STRING "3.4.0"
#define MBEDTLS_VERSION_STRING_FULL "mbed TLS 3.4.0"
```
openssl version:
```c
OpenSSL 1.1.1 11 Sep 2018
```
Hi,
I am currently working on PSA driver for our SoC's security crypto-processor. This processor needs to do some handling when a key is destroyed.
In the current implementation in mbedTLS, I don't see a driver wrapper function available in psa_destroy_key(). Is there a specific reason for not having wrapper for driver function available for psa_destroy_key() ?
Another query pertaining to the tests in the testsuite in mbedTLS. I was exploring if I could reuse the tests for the crypto-processor implementation. Have these been written with this kind of reuse in mind ?
Basically I would like the ability to add driver location to the cases. The few cases I have looked at for psa seem to be very specific. Any pointers/suggestions if anyone is reusing this test suite to test their specific PSA drivers?
Regards,
Ruchika
Hi All,
Thank you for sharing the MBED-TLS open source platform.
I need help with on of the crashes that I am observing right now. Below are my setup details:
Below are my setup details:
System information
Client side setup
Platform : Micro controller based platform stm32
OS : FreeRTOS
Compiler: gcc-arm-none-eabi-8-2019-q3-update
Below is the backtrace:
(gdb) bt
#0 panicCB (file=0xc94d7 "memory", line=734, message=0x2000ff50 <sli_wisun_event_loop_task_stack+4224> "Ajay Malloc Failed 88")
at build/3pp/freertos/FreeRTOS/Source/include/../../Source/portable/GCC/ARM_CM3/portmacro.h:237
#1 0x0003b2ae in panicHalt_ (file=file@entry=0xc94d7 "memory", line=line@entry=734, message=<optimized out>) at src/platform/core/assert.c:34
#2 0x0003bf0a in reallocInternal (p=<optimized out>, size=68, zeroFill=<optimized out>, file=0xc94d7 "memory", line=734) at src/platform/core/memory.c:317
#3 0x0003c2d8 in reallocWrapper (p=p@entry=0x0, size=<optimized out>, zeroFill=zeroFill@entry=true, file=file@entry=0xc94d7 "memory", line=line@entry=734) at src/platform/core/memory.c:673
#4 0x0003c350 in platformCalloc (n=<optimized out>, size=<optimized out>) at src/platform/core/memory.c:734
#5 0x00043dac in mbedtls_mpi_grow (nblimbs=17, X=0x2001001c <sli_wisun_event_loop_task_stack+4428>) at build/3pp/mbedtls/library/bignum.c:125
#6 mbedtls_mpi_grow (X=0x2001001c <sli_wisun_event_loop_task_stack+4428>, nblimbs=17) at build/3pp/mbedtls/library/bignum.c:115
#7 0x0004414a in mbedtls_mpi_shift_l (X=X@entry=0x2001001c <sli_wisun_event_loop_task_stack+4428>, count=count@entry=256) at build/3pp/mbedtls/library/bignum.c:1016
#8 0x00044818 in mbedtls_mpi_div_mpi (Q=Q@entry=0x0, R=R@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>, A=A@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>,
B=B@entry=0x200101d0 <sli_wisun_event_loop_task_stack+4864>) at build/3pp/mbedtls/library/bignum.c:1812
#9 0x00044a46 in mbedtls_mpi_mod_mpi (R=R@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>, A=A@entry=0x200100bc <sli_wisun_event_loop_task_stack+4588>,
B=B@entry=0x200101d0 <sli_wisun_event_loop_task_stack+4864>) at build/3pp/mbedtls/library/bignum.c:1917
#10 0x00046486 in ecdsa_verify_restartable (grp=grp@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>,
buf=buf@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", blen=blen@entry=32,
Q=Q@entry=0x2001020c <sli_wisun_event_loop_task_stack+4924>, r=r@entry=0x20010120 <sli_wisun_event_loop_task_stack+4688>, s=s@entry=0x2001012c <sli_wisun_event_loop_task_stack+4700>, rs_ctx=0x0)
at build/3pp/mbedtls/library/ecdsa.c:649
#11 0x00046660 in mbedtls_ecdsa_read_signature_restartable (ctx=ctx@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>,
hash=hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hlen=hlen@entry=32,
sig=sig@entry=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, slen=slen@entry=70, rs_ctx=rs_ctx@entry=0x0) at build/3pp/mbedtls/library/ecdsa.c:881
#12 0x0004668e in mbedtls_ecdsa_read_signature (ctx=ctx@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>,
hash=hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hlen=hlen@entry=32,
sig=sig@entry=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, slen=slen@entry=70) at build/3pp/mbedtls/library/ecdsa.c:832
#13 0x0004a830 in ecdsa_verify_wrap (ctx=ctx@entry=0x20010184 <sli_wisun_event_loop_task_stack+4788>, md_alg=md_alg@entry=MBEDTLS_MD_SHA256,
hash=hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hash_len=hash_len@entry=32,
sig=sig@entry=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=sig_len@entry=70) at build/3pp/mbedtls/library/pk_wrap.c:633
#14 0x0004a872 in eckey_verify_wrap (ctx=<optimized out>, md_alg=<optimized out>,
hash=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hash_len=32,
sig=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=70) at build/3pp/mbedtls/library/pk_wrap.c:252
#15 0x0004a3de in mbedtls_pk_verify (ctx=ctx@entry=0x2001ce48, md_alg=<optimized out>, hash=<optimized out>, hash_len=<optimized out>,
sig=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=70) at build/3pp/mbedtls/library/pk.c:326
#16 0x0004a55c in mbedtls_pk_verify_ext (type=<optimized out>, options=<optimized out>, ctx=ctx@entry=0x2001ce48, md_alg=<optimized out>, hash=<optimized out>,
hash@entry=0x200102a4 <sli_wisun_event_loop_task_stack+5076> "c;\371\274\231xF\004 \207\005\271\257\177\266\224\234\212\205Є\331\366D\304L<\243\303f\246j\250\370\001 ", hash_len=<optimized out>,
hash_len@entry=32,
sig=0x2001d2e1 "0D\002 r\203\237\331\v\346J*m\312\326\346\004+\a\377\373bX\016\233خ\346\030\356\311Nk\270\341L\002 h;\b\301\206\215\346\005\021c\"|\026\353𦕟\327\300ģ\221\\\324s\n^GW", <incomplete sequence \314>, sig_len=70) at build/3pp/mbedtls/library/pk.c:390
#17 0x0004feb4 in x509_crt_check_signature (rs_ctx=<optimized out>, parent=0x2001cd7c, child=0x2001f8a8) at build/3pp/mbedtls/library/x509_crt.c:2474
#18 x509_crt_find_parent_in (rs_ctx=<optimized out>, self_cnt=<optimized out>, path_cnt=<optimized out>, top=<optimized out>, r_signature_is_good=<optimized out>, r_parent=<optimized out>, candidates=<optimized out>,
child=<optimized out>) at build/3pp/mbedtls/library/x509_crt.c:2612
#19 x509_crt_find_parent (rs_ctx=<optimized out>, self_cnt=<optimized out>, path_cnt=<optimized out>, signature_is_good=<optimized out>, parent_is_trusted=<optimized out>, parent=<optimized out>,
trust_ca=<optimized out>, child=<optimized out>) at build/3pp/mbedtls/library/x509_crt.c:2709
#20 x509_crt_verify_chain (f_ca_cb=0x0, p_ca_cb=0x0, rs_ctx=0x0, ver_chain=0x200102c4 <sli_wisun_event_loop_task_stack+5108>, profile=0xcd08c <mbedtls_x509_crt_profile_default>, ca_crl=0x0, trust_ca=0x2001cd7c,
crt=0x2001f8a8) at build/3pp/mbedtls/library/x509_crt.c:2919
#21 x509_crt_verify_restartable_ca_cb (crt=crt@entry=0x2001f8a8, trust_ca=trust_ca@entry=0x2001cd7c, ca_crl=0x0, profile=0xcd08c <mbedtls_x509_crt_profile_default>, cn=0x0, flags=0x2001dd30,
f_vrfy=0x695f1 <tls_sec_prot_lib_x509_crt_verify>, p_vrfy=0x2001c8a0, rs_ctx=0x0, p_ca_cb=0x0, f_ca_cb=0x0) at build/3pp/mbedtls/library/x509_crt.c:3150
--Type <RET> for more, q to quit, c to continue without paging--
#22 0x00050090 in mbedtls_x509_crt_verify_restartable (crt=crt@entry=0x2001f8a8, trust_ca=trust_ca@entry=0x2001cd7c, ca_crl=<optimized out>, profile=<optimized out>, cn=0x0, flags=0x2001dd30,
f_vrfy=0x695f1 <tls_sec_prot_lib_x509_crt_verify>, p_vrfy=0x2001c8a0, rs_ctx=rs_ctx@entry=0x0) at build/3pp/mbedtls/library/x509_crt.c:3258
#23 0x00058f7c in ssl_parse_certificate_verify (rs_ctx=0x0, chain=0x2001f8a8, authmode=<optimized out>, ssl=0x2001c918) at build/3pp/mbedtls/library/ssl_tls.c:2542
#24 mbedtls_ssl_parse_certificate (ssl=ssl@entry=0x2001c918) at build/3pp/mbedtls/library/ssl_tls.c:2795
#25 0x00051d1c in mbedtls_ssl_handshake_client_step (ssl=0x2001c918) at build/3pp/mbedtls/library/ssl_cli.c:4295
#26 0x00058210 in mbedtls_ssl_handshake_step (ssl=0x2001c918) at build/3pp/mbedtls/library/ssl_tls.c:5668
#27 0x00069922 in tls_sec_prot_lib_process ()
#28 0x0006b442 in client_tls_sec_prot_state_machine ()
#29 0x00069af8 in tls_sec_prot_receive ()
#30 0x00068072 in supp_eap_tls_sec_prot_state_machine ()
#31 0x000627b8 in supp_eap_tls_sec_prot_receive ()
#32 0x0006d28c in kmp_eapol_pdu_if_receive ()
#33 0x0007d602 in ws_eapol_pdu_mpx_data_indication ()
#34 0x00080f2e in ws_llc_mac_indication_cb.lto_priv ()
#35 0x000a8df6 in mac_mcps_sap_data_tasklet.lto_priv ()
#36 0x000ae3f8 in event_loop_thread.lto_priv ()
#37 0x000414c0 in xEventGroupSetBitsFromISR (xEventGroup=<optimized out>, uxBitsToSet=<optimized out>, pxHigherPriorityTaskWoken=<optimized out>) at build/3pp/freertos/FreeRTOS/Source/event_groups.c:724
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
(gdb)
I see a crash while my node is trying to authenticate using EAP-TLS to a gateway.
I am able to consistently reproduce observe this issue.
Is this something that has been already solved or is seen by anybody ?
Any inputs on this will help.
With regards,
Ajay.
Hi,
i wanted to ask if the hardware accelerators and TRNG of the Hardware
Security Engine (HSE) of NXP S32K3XX microcontrollers are supported by the
mbedTLS Library ? because i can't find it in the "MBEDTLS HARDWARE
CRYPTOGRAPHY SUPPORT" list.
Best regards,
Ben
+ Mbed TLS mailing list for visibility…
Regards,
Shebu
From: Rehan Malak via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Monday, July 10, 2023 9:44 AM
To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Re: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ?
Hi Antonio,
Thanks a lot for your answer !
Looking at the MbedTLS github link you sent (and the one therein)
- https://github.com/Mbed-TLS/mbedtls/issues/6228 PSA: separate driver initialization with a nicer fixed ordering
- https://github.com/Mbed-TLS/mbedtls/issues/6007 Define the PSA subsystem initialization interface in Mbed TLS
it seems that for the best would be indeed to provide feedback to the MbedTLS/PSA team such that TF-M could just run the adequate psa_* functions.
Thanks !
Rehan
Intrinsic ID
________________________________
From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>
Sent: Saturday, July 8, 2023 12:13 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Rehan Malak <Rehan.Malak(a)intrinsic-id.com<mailto:Rehan.Malak@intrinsic-id.com>>
Subject: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ?
Hi Rehan,
This looks like a non-PSA standardized feature specific to mbed TLS. We don't have any platform in TF-M that requires such setup/teardown so I can't comment from experience, but to me it looks like this would be an mbed TLS specific feature that needs to be hooked underneath the service and into the library. The most natural choice would be indeed to have them as part of the psa_crypto_init() and lower functions, but at this stage I think is not possible to implement this without patching the source code (i.e. there are no options to allow this at build time in TF-M, at least).
Note also that mbed TLS has a on open ongoing issue to better define the initialisation sequence for the various operations in psa_crypto_init(): PSA: separate driver initialization with a nicer fixed ordering · Issue #6228 · Mbed-TLS/mbedtls (github.com)<https://github.com/Mbed-TLS/mbedtls/issues/6228> It might be a good place to start to provide feedback regarding this particular aspect of custom platform initialisation if is not being considered there.
To conclude, if you want to propose a patch for TF-M to allow such functions to be plugged in (in the meantime that mbed TLS agrees on the long term course of action), I will be happy to review it.
Thanks,
Antonio
________________________________
From: Rehan Malak via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Friday, July 7, 2023 13:15
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] mbedtls_platform_setup/teardown in TF-M ?
Dear TF-M developers,
I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto.
At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite :
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui…
But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown.
And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called :
? -> mbedtls_platform_setup
? -> mbedtls_platform_teardown
At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem :
tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init
? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free
Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ?
If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…
or is there a nicer way of doing this ?
(btw, I am currently experimenting on qemu mps2-an521)
Thanks for any advice ! 🙂
Best regards,
Rehan MALAK
Intrinsic ID
Hello,
This is a question for integrators and packagers of Mbed TLS, especially
if you're integrating the library in some embedded OS or BSP.
To build, configure and test Mbed TLS, we use Python for several purposes:
* To configure the library with scripts/config.py, unless you use the
default configuration or write your own configuration from scratch.
* To generate some configuration-independent library source files, but
only if you use the development branch, not if you use a release or
an LTS branch.
* To generate some glue code for PSA drivers, if you use PSA drivers
and don't write the glue code by hand.
* To generate the unit test source files.
* (We have many more maintenance and test scripts but they're out of
scope here.)
(Python is not necessary, and will remain unnecessary, to configure and
build the library with a given set of hardware drivers, so that a
typical BSP will not have to depend on Python.)
For each of these purposes, how problematic is it if we require a recent
version of Python? We're currently planning to drop support for older
versions of Python as soon as they become unsupported upstream (so
officially dropping 3.8 now — although right now all scripts still work
on 3.5). This includes versions of Python that are still shipped in e.g.
Linux distributions that are themselves officially supported. Is there
demand for supporting older Python versions for some scripts?
Also, how problematic is it if some of these purposes require
third-party Python packages?
Best regards,
--
Gilles Peskine
Mbed TLS developer
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
FYI to all TF dev teams leveraging Open CI.
Best regards,
Don
---------- Forwarded message ---------
From: Glen Valante via Tf-openci-triage <
tf-openci-triage(a)lists.trustedfirmware.org>
Date: Fri, 23 Jun 2023 at 08:41
Subject: [Tf-openci-triage] FYI; Cambridge Lab Down
To: tf-openci-triage(a)lists.trustedfirmware.org <
tf-openci-triage(a)lists.trustedfirmware.org>
Hello All;
FYI; the Cambridge lab took a serious power hit and is down. They are
scrambling to get things back up, but it may take all weekend.
Expect LAVA failures and other strange results.
Thanks;
-g
--
[image: Linaro] <http://www.linaro.org>
Glen Valante | *Director Program & Project Management*
T: +1.508.517.3461 <1617-320-5000>
glen.valante(a)linaro.org | Skype: gvalante <callto:gvalante>
--
Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org
To unsubscribe send an email to
tf-openci-triage-leave(a)lists.trustedfirmware.org
Dear sir/madam,
Hope you are doing good!
We are working on a lightweight TLS implementation for embedded hardware
and want to add our own algorithm inside mbedTLS. As per my knowledge, we
have to add a .h file in mbedtls/include/mbedtls and .c file in the
library. Also, we have to list our algorithm in library/CMakeLists.txt.
Except these, what should be the procedure?
Also, our task is during handshake, the receiver chooses our algorithm
instead of the default one for encryption and decryption. If someone could
help us regarding this then it would be great.
Thanks in advance.
Regards,
--
*Dr. Vishal J. Rathod*
*(Member - IEEE, ACM, IET)*
*Senior Project Engineer (SPE),*
*IoT R & D Group,*
*C-DAC, Electronic City,*
*Bengaluru, Karnataka, India.*
*Email ID: rathodvishal78(a)gmail.com <rathodvishal78(a)gmail.com> and *
vishalrathod(a)ieee.org
*Mobile - 9879957770*
Hi!
I am a new MbedTLS user and would like to say thanks to devs first!
From my point of view mbedtls_net_connect() could handle binding socket to a specified local client port.
Although it does not seem to be a common requirement and bloats API a little bit but otherwise user has to throw away mbedtls_net_connect()
and implement connection function by their hands.
Best,
Alex
Hi Ruchika,
as an addition to the previous answers, there is also the SecureMark-TLS benchmark from EEMBC that "Analyzes the costs associated with implementing TLS on an edge device using a common IoT cyphersuite comprised of ECC & ECDSA on the NIST secp256r1 curve, SHA256, and AES128-CCM/ECB", see: https://www.eembc.org/securemark/
It provides profiles to run benchmarks against Mbed TLS API, PSA Crypto API, and wolfSSL, see sources here: https://github.com/eembc/securemark-tls/tree/main/examples/selfhosted/profi…
The chosen cipher-suite is similar to the TF-M medium profile and it allows estimates of speed and power consumption for TLS on microcontrollers. It also allows to add - manually - footprint data.
Best
Stephan
From: Ruchika Gupta via psa-crypto <psa-crypto(a)lists.trustedfirmware.org>
Reply to: Ruchika Gupta <ruchika.gupta_1(a)nxp.com>
Date: Tuesday, 16 May 2023 at 13:40
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>, "psa-crypto(a)lists.trustedfirmware.org" <psa-crypto(a)lists.trustedfirmware.org>
Subject: [psa-crypto] Benchmark application for PSA crypto API's
Hi,
For mbedtls API’s, there is a benchmark application available. Are there any plans to implement benchmark application for PSA crypto APIs ?
Regards,
Ruchika
Hi,
For mbedtls API's, there is a benchmark application available. Are there any plans to implement benchmark application for PSA crypto APIs ?
Regards,
Ruchika
Hello,
In mbedLS v3.4.0, I came across a build error that there are no members for type and flag in psa_core_keyattributes_t structure.
The following functions in psa_crypto_core.h access private members type and flag of psa_core_keyattributes_t structure without the MBEDTLS_PRIBATE() private access.
* psa_is_key_slot_occupied()
* psa_key_slot_get_flags()
* psa_key_slot_set_flags()
* psa_key_slot_set_bits_in_flags()
* psa_key_slot_clear_bits()
Updating to private access for attribute struct members in psa_crypto_core.h fixed the build errors.
Regards,
Archanaa
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
This event has been canceled with a note:
"Cancelled due to Bank Holiday"
MBed TLS Technical Forum
Monday May 8, 2023 ⋅ 8:30am – 9:30am
Mountain Standard Time - Phoenix
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: MBed TLS Technical Forum
Time: Oct 25, 2021 04:30 PM London
Every 4 weeks on Mon, 20 occurrence(s)
Oct 25, 2021 04:30 PM
Nov 22, 2021 04:30 PM
Dec 20, 2021 04:30 PM
Jan 17, 2022 04:30 PM
Feb 14, 2022 04:30 PM
Mar 14, 2022 04:30 PM
Apr 11, 2022 04:30 PM
May 9, 2022 04:30 PM
Jun 6, 2022 04:30 PM
Jul 4, 2022 04:30 PM
Aug 1, 2022 04:30 PM
Aug 29, 2022 04:30 PM
Sep 26, 2022 04:30 PM
Oct 24, 2022 04:30 PM
Nov 21, 2022 04:30 PM
Dec 19, 2022 04:30 PM
Jan 16, 2023 04:30 PM
Feb 13, 2023 04:30 PM
Mar 13, 2023 04:30 PM
Apr 10, 2023 04:30 PM
Please download and import the following iCalendar (.ics) files to your
calendar system.
Weekly:
https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics…
Join Zoom Meeting
https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT…
Meeting ID: 959 6263 5632
Passcode: 018366
One tap mobile
+13462487799,,95962635632# US (Houston)
+16699009128,,95962635632# US (San Jose)
Dial by your location
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Washington DC)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 959 6263 5632
Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y
Guests
nnac123(a)gmail.com
psa-crypto(a)lists.trustedfirmware.org
mbed-tls(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hello,
To strengthen Mbed TLS against accidental misuse, we're going to enforce
a minimum size for RSA key generation. Currently the minimum is 128
bits, just to avoid some edge cases in the implementation. So for
example, if you want a 2048-bit key but accidentally pass a number of
bytes, the library will happily generate a 256-bit key. We want to
prevent this scenario.
What should the minimum be? If we make the minimum 2048 bits, will this
be a problem? We will not make the minimum any higher. But we're
considering enforcing only a minimum 1024 bits, which is over the record
from public breaks and largely resolves the risk of bits/bytes confusion.
Should we also enforce a minimum (perhaps lower) in the 2.28 long-time
support branch?
If you're using Mbed TLS to generate small RSA keys, please let us know
on the mailing list, on GitHub at
https://github.com/Mbed-TLS/mbedtls/issues/7556, or by private email.
Best regards,
--
Gilles Peskine
Mbed TLS developer
MBed TLS Technical Forum
Every 4 weeks from 9:30am to 10:30am on Monday
Mountain Standard Time - Phoenix
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: MBed TLS Technical Forum
Time: Oct 25, 2021 04:30 PM London
Every 4 weeks on Mon, 20 occurrence(s)
Oct 25, 2021 04:30 PM
Nov 22, 2021 04:30 PM
Dec 20, 2021 04:30 PM
Jan 17, 2022 04:30 PM
Feb 14, 2022 04:30 PM
Mar 14, 2022 04:30 PM
Apr 11, 2022 04:30 PM
May 9, 2022 04:30 PM
Jun 6, 2022 04:30 PM
Jul 4, 2022 04:30 PM
Aug 1, 2022 04:30 PM
Aug 29, 2022 04:30 PM
Sep 26, 2022 04:30 PM
Oct 24, 2022 04:30 PM
Nov 21, 2022 04:30 PM
Dec 19, 2022 04:30 PM
Jan 16, 2023 04:30 PM
Feb 13, 2023 04:30 PM
Mar 13, 2023 04:30 PM
Apr 10, 2023 04:30 PM
Please download and import the following iCalendar (.ics) files to your
calendar system.
Weekly:
https://linaro-org.zoom.us/meeting/tJEkceuurT4sGdaksikbUn6FARB9Kuk3ac2o/ics…
Join Zoom Meeting
https://linaro-org.zoom.us/j/95962635632?pwd=STFkQVltejAzRDJ6NmoxZjhmZC9RUT…
Meeting ID: 959 6263 5632
Passcode: 018366
One tap mobile
+13462487799,,95962635632# US (Houston)
+16699009128,,95962635632# US (San Jose)
Dial by your location
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Washington DC)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 959 6263 5632
Find your local number: https://linaro-org.zoom.us/u/aewUpnQu5y
Guests
psa-crypto(a)lists.trustedfirmware.org
mbed-tls(a)lists.trustedfirmware.org
nnac123(a)gmail.com
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm…
Reply for mbed-tls(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=ZGExMnNqcDB1MDFm…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hello,
using mbed TLS pavkaged with esp32 toolchain, for doing eap-tls with server certificate verification using CA cert.
Mbed TLS rejects certificate in mbedtls_x509_crt_check_key_usage (x509_crt.c), because usage_may variable is 0.
usage is set by mbedtls_ssl_check_cert_usage (ssl_tls.c) to MBEDTLS_X509_KU_DIGITAL_SIGNATURE because my keys are ECDHE-ECDSA.
Is this the expected behaviour ?
Thanks in advance
François
Hello,
I was working on packaging up mbedtls for [tea, a new package manager](https://tea.xyz/) and ran into an error validating the built products. I was hoping maybe someone more knowledgeable could take a quick look.
I followed the homebrew formula here: https://github.com/Homebrew/homebrew-core/blob/af8e7e97432944a65c0f985132a7…
Here's the PR for adding it to tea: https://github.com/teaxyz/pantry/pull/1822
For some reason I'm not getting the expected checksum from `generic_sum`. Any help would be much appreciated. Thanks!
-Joe
Hi Team,
I want to implement TLS over UART using MbedTLS library, But the issue i am facing right now is There are no example codes or any reference document for briefing how to import the libraries and what changes should be done to do so.
I tried to use some examples for Lwip examples but i am getting errors while importing library like platform error, timing_alt.h error.
Please help me out in urgent.
Thanks !!
I have created an http server following the example for server1 under FreeRTOS and Lwip running on a STM32H753 using the Stm32CubeIDE. Everything seem to work correctly, however, I am experiencing a small memory leak over each successive TLS connection of 160 bytes. It is obvious that I must not be freeing a context, but as I am following the example very closely, except for running the code in a FreeRTOS thread, I must be missing something fundemental. Has anyone on this list experienced a similar issue or have any ideas on how to debug it?
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next Monday at 10:00am PM UK time. Invite details can be found on
the online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org