Hi All,
FYI, per Shebu, I'm adding both mbed-tls(a)lists.trustedfirmware.org and
psa-crypto(a)lists.trustedfirmware.org to the MBed TLS Tech Forum invites.
Please look for this in your inbox and accept it if you would like the
series added to your calendar.
- Note that this is a monthly meeting but you will see two invites, one
that is for Asia timezones and one for Europe/US. Just delete the series
that isn't timezone friendly for you.
- FYI, recall that this and other tech forums can be found in the meeting
calendar on the TF website <https://www.trustedfirmware.org/meetings/>.
If you see a meeting in that calendar, click on the entry and an option
comes up saying "copy to my calendar." It will import that single instance
into your personal calendar from there if you wish. I wasn't able to test
this feature with outlook, but it worked fine for google calendar.
Please let me know if you have any questions.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello!
OpenVPN can be compiled with OpenSSL or mbedtls. However, OpenVPN is licensed under GPLv2 only. If I understand correctly, that means it is not legal to distribute binaries of OpenVPN that are linked with mbedtls 2.17 or later.
At Fox Crypto, we produce a hardened version of OpenVPN, called OpenVPN-NL, for use by the Dutch government, which uses mbedtls. (The latest release is rather old and still uses 2.16.)
Is there anyone I could ask about making an exception for linking OpenVPN with mbedtls?
Regards,
Max Fillinger
Hello,
I want to test/analyze the performance increase of using tinycrypt for ECC operations instead of the standard MbedTLS ECC functions. Could you please help me with a few answers regarding this?
I am aware that tinycrypt is already integrated in the baremetal branch. Do you happen to know what is the performance increase of using this tinycrypt uECC implementation instead of the standard one on arm cortex m4 microcontrollers?
I would like to port the tinycrypt uECC changes from baremetal branch to a Mbed TLS 2.25.0 version used in Matter repo (from where Mbed TLS repo is refered), more exactly this commit: https://github.com/ARMmbed/mbedtls/tree/1c54b5410fd48d6bcada97e30cac417c5c7…
What do you think is the best approach? I thought of forking Mbed TLS, creating a separate branch with that commit and adding there the tinycrypt changes from baremetal branch. However, I'm not sure how to proceed next since the Matter repo refers the MbedTLS repo. Is this approach ok?
Thank you!
Hi,
I have completed my job on these topics so I would like to unsubscribe from this mailing list, can you help me?
Thank you!
Michele
[cid:image001.png@01D7FCCB.D711FD40]
Hillrom is now a part of Baxter
Michele Innocenti
Sr Principal Engineer, SW Eng
Gambro Dasco S.p.A.
Via Modenese 66 / 41036 Medolla, Modena, Italy
T. +39 0535.50578
michele_innocenti(a)baxter.com<mailto:michele_innocenti@baxter.com>
Dear all,
mbedtls 3.x is incompatible with mbedtls 2.x so the transition of all
the packages using mbedtls will take a long time. However, from my
understanding, it is not possible to install both versions side by
side as a lot of headers are common to both versions and installed in
include/mbedtls.
This fact is raising concern on buildroot side, see:
https://patchwork.ozlabs.org/project/buildroot/patch/20211228153345.4087026…
Can you confirm that a side-by-side installation of both mbedtls versions
is not possible and/or can you share some inputs on this topic?
Best Regards,
Fabrice
Hi,
We are pleased to announce the release of Mbed TLS 2.16.12, 2.28.0 and 3.1.0.
These releases of Mbed TLS address several security issues, provide bug fixes, and new features, including initial support for TLS 1.3 in Mbed TLS 3.1.0.
Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/v3.1.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.28.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.12).
Mbed TLS 2.16.12 will be the last release in the 2.16 LTS; it will no longer be supported.
Mbed TLS 2.28 is the new long-term support release, and will be supported with bug-fixes and security fixes until end of 2024.
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Dave Rodgman
Dear MBedTLS-Team,
we are currently evaluating MBedTLS for use in our Product. We develop
an implant for blood pressure patients, and our implant and its charger
need to communicate securely. We already have an AES encrypted
communication running, but so far we just store the password in every
device, and we would like to switch to RSA to exchange an AES key. It
would also be important for us to be able to validate an x509
certificate on the implant. However, due to energy constraints, our
internal flash memory on the implant is extremely small, and we would
like to not parse the certificate on the implant, but rather send only
the key and the signature directly, and then "validate by hand" on the
implant. If I understand the procedure correctly, that would only
involve taking a hash of the pubkey, decrypting the signature with a
stored CA-public key, and compare them, correct? Would that be possible?
Besides normal support during our implementation phase, we would be
interested in being informed whenever a vulnerability is found in
MBedTLS and a fast update. Do you offer such a service? If so, what will
it cost?
Kind Rergards,
Felix Knorr
--
Mit freundlichen Grüßen neuroloop GmbH
i.A. Felix Knorr
Senior Software Developer
--------------------------------------
neuroloop GmbH
Engesserstr. 4, 79108 Freiburg, Germany
Amtsgericht Freiburg HRB 713935
Geschäftsführer: Dr. Michael Lauk, Dr. Dennis Plachta
The information contained in this communication is confidential, may be attorney-client privileged, may constitute inside information, and is intended only for the use of the addressee. It is the property of the company of the sender of this e-mail. Unauthorized use, disclosure, or copying of this communication or any part thereof is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by return e-mail and destroy this communication and all copies thereof, including all attachments.
Hi,
I am trying to encrypt data on my rabbitmq communication.
On the rabbitmq server end I am using the openssl and on the client end I cant use openssl but I can use mbedtls.
I am using mbedtls-2.26.0 version in my rabbimq-c client .
The certificate is generated via https://github.com/michaelklishin/tls-gen
The certificate is valid and has no issue because the communication works fine when I use the ssl_client2 and ssl_server2 applications from the mbedtls-2.26.0\programs.
The communication works fine when I use the rabbitmq openssl client and openssl server.
But when I try to use the rabbitmq openssl server and ssl_client2 from mbedtls-2.26.0\programs the connection is reset.
I think it’s a config issue but I am not able to figure out the solution or the rootcause.
I am not sure if I can use mbedtls client with openssl server.
Could you please help me in this.
Below is the log from wireshark. Attached is the log from sslclient2 program.
After the certificate is verified the broker resets the connection
TCP 60271 → 5671 [SYN] Seq=0 Win=65535 Len=0 MSS=65475 WS=256 SACK_PERM=1
TCP 5671 → 60271 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65475 WS=256 SACK_PERM=1
TCP 60271 → 5671 [ACK] Seq=1 Ack=1 Win=2618880 Len=0
TLSv1.2 Client Hello
TCP 5671 → 60271 [ACK] Seq=1 Ack=305 Win=2618880 Len=0
TLSv1.2 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
TCP 60271 → 5671 [ACK] Seq=305 Ack=1976 Win=2616832 Len=0
TLSv1.2 Certificate
TCP 5671 → 60271 [ACK] Seq=1976 Ack=945 Win=2618112 Len=0
TLSv1.2 Client Key Exchange
TCP 5671 → 60271 [ACK] Seq=1976 Ack=1088 Win=2618112 Len=0
TLSv1.2 Certificate Verify
TCP 5671 → 60271 [ACK] Seq=1976 Ack=1173 Win=2618112 Len=0
TLSv1.2 Change Cipher Spec
TCP 5671 → 60271 [ACK] Seq=1976 Ack=1179 Win=2618112 Len=0
TLSv1.2 Encrypted Handshake Message
TCP 5671 → 60271 [ACK] Seq=1976 Ack=1216 Win=2617856 Len=0
TLSv1.2 Change Cipher Spec, Encrypted Handshake Message
TCP 60271 → 5671 [ACK] Seq=1216 Ack=2019 Win=2616832 Len=0
TLSv1.2 Application Data
TCP 5671 → 60271 [ACK] Seq=2019 Ack=1245 Win=2617856 Len=0
TLSv1.2 Application Data
TCP 60271 → 5671 [ACK] Seq=1245 Ack=2048 Win=2616832 Len=0
TLSv1.2 Encrypted Alert
TCP 60271 → 5671 [ACK] Seq=1245 Ack=2071 Win=2616832 Len=0
TCP 5671 → 60271 [RST, ACK] Seq=2071 Ack=1245 Win=0 Len=0
Thanks,
Shailaja
Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
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