Hello, I hope you are going well during this Covid crisis.
I'm sending you this message to find out how to generate a Diffie Hellman key using MbedTLS. Indeed, with all the documentation, I'm a bit lost.
I think, you have to use the int mbedtls_dhm_set_group function to create p and g. And then, I don't know how to use which function... Moreover, I can't find any function that allows to set a and b, whereas they are 2 fundamental elements
Can you help me? Thank you!
Best regards, YS
Hi Frank,
We have now updated the links both on the download-archive and releases site and now they point to https://github.com/ARMmbed/mbedtls/releases, where all the releases are available.
We also have added checksums to the release notes on github and fixed the archive structure.
Thank you very much for pointing these issues out!
Cheers,
Janos
(Mbed TLS developer)
On 04/08/2020, 19:06, "mbed-tls on behalf of Frank Bergmann via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote:
Hi,
2.16.7 was released on github more than one month ago (2020-07-01).
But it is not listed on
- download archive at https://tls.mbed.org/download-archive
- release news at https://tls.mbed.org/tech-updates/releases
Questions about that:
- Is it an "official" release even if it is not mentioned on release news?
- When will it be available in download archive?
- If there will be no more addings to download archive because now we'll
have to use github:
* Will there be separate releases GPL/Apache available?
* Will a signed/unsigned check sum be provided?
* Will the "new structure" as provided by tarball on github be kept
in future or was it just an accident? (e.g. main dir is named
"mbedtls-mbedtls-2.16.7")
I started using mbed TLS with 2.16.6 but now I am confused. ;-)
cheers,
Frank
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi Frank,
I confirm that 2.16.7 is an official release of the 2.16 long-time
support branch of Mbed TLS, alongside 2.7.16 for the 2.7 branch and
2.23.0 for the latest features. Everyone should update to one of these
versions since they fix security issues and other bugs.
We're progressively transitioning the project from Arm infrastructure to
TrustedFirmware infrastructure. Eventually we'll decommission the
existing tls.mbed.org, and we intend to distribute releases via
trustedfirmware.org. We no longer intend to reference new releases
directly on https://tls.mbed.org/download-archive . For the time being,
we're distributing via GitHub. However, it isn't right that
https://tls.mbed.org/download-archive links to
https://github.com/ARMmbed/mbedtls/releases/ which doesn't list LTS
branches. We need to link from https://tls.mbed.org/download-archive to
the place that has the latest LTS releases one way or the other.
There are no longer separate archives with Apache and GPL licenses.
These archives were always identical except for license headers. Now LTS
releases are distributed as a single archive in which the files are
dual-licensed.
The naming with mbedtls-mbedtls- must be a bug in our release script.
Thanks for noticing.
I don't think we made a conscious decision not to provide official
checksums. I can see the value of having them so let's try to
incorporate those in our new release process.
--
Gilles Peskine
Mbed TLS developer
On 04/08/2020 19:05, Frank Bergmann via mbed-tls wrote:
> Hi,
>
> 2.16.7 was released on github more than one month ago (2020-07-01).
> But it is not listed on
> - download archive at https://tls.mbed.org/download-archive
> - release news at https://tls.mbed.org/tech-updates/releases
>
> Questions about that:
> - Is it an "official" release even if it is not mentioned on release news?
> - When will it be available in download archive?
> - If there will be no more addings to download archive because now we'll
> have to use github:
> * Will there be separate releases GPL/Apache available?
> * Will a signed/unsigned check sum be provided?
> * Will the "new structure" as provided by tarball on github be kept
> in future or was it just an accident? (e.g. main dir is named
> "mbedtls-mbedtls-2.16.7")
>
> I started using mbed TLS with 2.16.6 but now I am confused. ;-)
>
> cheers,
> Frank
>
>
Hi,
2.16.7 was released on github more than one month ago (2020-07-01).
But it is not listed on
- download archive at https://tls.mbed.org/download-archive
- release news at https://tls.mbed.org/tech-updates/releases
Questions about that:
- Is it an "official" release even if it is not mentioned on release news?
- When will it be available in download archive?
- If there will be no more addings to download archive because now we'll
have to use github:
* Will there be separate releases GPL/Apache available?
* Will a signed/unsigned check sum be provided?
* Will the "new structure" as provided by tarball on github be kept
in future or was it just an accident? (e.g. main dir is named
"mbedtls-mbedtls-2.16.7")
I started using mbed TLS with 2.16.6 but now I am confused. ;-)
cheers,
Frank
Hi Youssouf,
This is Steven with Silicon Labs. It sounds like you have questions that are very device-specific, and relate to Silicon Labs products. We do provide TRNG drivers for mbed TLS through Simplicity Studio and our software SDK. Please contact our support staff at www.silabs.com/support<http://www.silabs.com/support>, and they’ll do their best to help you out with your questions.
Regards,
-- Steven
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of youssouf sokhona via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: youssouf sokhona <youssouf.sokhona(a)hotmail.fr>
Date: Tuesday, 4 August 2020 at 12:59
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Entropy & TRNG on the BGM13P32
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi, everyone,
First of all, I hope you are all healthy during this difficult time.
I am working with Simplicity Studio IDE with MbedTLS and I am currently working on a project with a BGM13P32. I plan to perform a key exchange via bluetooth with the Diffie Hellman protocol. To start my project, I need an entropy source. I read the following on the BGM13P32 documentation "The TRNG is a non-deterministic random number generator based on a full hardware solution. The TRNG is validated with NIST800-22and AIS-31 test suites as well as being suitable for FIPS 140-2 certification (for the purposes of cryptographic key generation)."
And I also read about the Random Number Generator "The Frame Controller (FRC) implements a random number generator that uses entropy gathered from noise in the RF receive chain.The data is suitable for use in cryptographic applications.Output from the random number generator can be used either directly or as a seed or entropy source for software-based random num-ber generator algorithms such as Fortuna"
Knowing this, how can we use this to create entropy and then create a sequence of random numbers? I need to implement the MbedTLS_hardware_poll() function? Do I have to add another entropy, like real timing for example
As you can see I am a bit confused actually. Can you help me out?
Thanks in advance, and take care of yourself !
Hi, everyone,
First of all, I hope you are all healthy during this difficult time.
I am working with Simplicity Studio IDE with MbedTLS and I am currently working on a project with a BGM13P32. I plan to perform a key exchange via bluetooth with the Diffie Hellman protocol. To start my project, I need an entropy source. I read the following on the BGM13P32 documentation "The TRNG is a non-deterministic random number generator based on a full hardware solution. The TRNG is validated with NIST800-22and AIS-31 test suites as well as being suitable for FIPS 140-2 certification (for the purposes of cryptographic key generation)."
And I also read about the Random Number Generator "The Frame Controller (FRC) implements a random number generator that uses entropy gathered from noise in the RF receive chain.The data is suitable for use in cryptographic applications.Output from the random number generator can be used either directly or as a seed or entropy source for software-based random num-ber generator algorithms such as Fortuna"
Knowing this, how can we use this to create entropy and then create a sequence of random numbers? I need to implement the MbedTLS_hardware_poll() function? Do I have to add another entropy, like real timing for example
As you can see I am a bit confused actually. Can you help me out?
Thanks in advance, and take care of yourself !
Morning,
First of all, I hope you are all healthy during this difficult time.
I am working with Simplicity Studio IDE and with Mbed TLS and I am currently working on a project with a BGM13P32. I plan to write in a file some parameters that will allow a key exchange by bluetooth (Diffie Hellman Protocol). I intend to make the BGM13P32 read this file, and these data to allow a key exchange. Is it possible to do that? If yes, how?
Because I'm a total beginner
Thank you, and take care of yourself !
Hi all,
I have configured the max fragment length at the client and server to both 512. With this setting when I try to reconnect using a saved session at the client side, the ssl handshake doesn’t seem to happen.
Below is the comment in the server code.
/* We don't support fragmentation of ClientHello (yet?) */
The mbedtls code I am using is version 2.16.6. Are there any plans to support fragmentation of clienthello? Do let me know
Regards,
Fariya
Hi,
I do not quite have enough knowledge on DTLS session resumption .. nevertheless here's my question:
a) Difference between the features: MBEDTLS_SSL_COOKIE_C and MBEDTLS_SSL_SESSION_TICKETS?
b) Enabling the feature MBEDTLS_SSL_SESSION_TICKETS would be sufficient to resume an earlier established DTLS session quickly (i.e avoid the whole TLS handshake done the last time)?
c) How do I test this - i.e initiate connection from client and server, break the connection and then make the client connect to the server again? Not sure what additional steps are required on client side. Any callbacks to be registered in the code?
Regards,
Fariya
Hi Gilles,
I checked one you recommended and looks like it is very complicated.
Do you have any sample project(SSH client) based on MbedTLS+LWIP?
Thanks,
Christie
-----Original Message-----
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of mbed-tls-request(a)lists.trustedfirmware.org
Sent: July-22-20 11:35 AM
To: mbed-tls(a)lists.trustedfirmware.org
Subject: mbed-tls Digest, Vol 5, Issue 15
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
or, 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. Problem with decrypt aes 128 in ecb mode. HELP ME!
(dany_banik2000(a)yahoo.com)
2. Re: SSH client sample (Gilles Peskine)
3. Re: patches for low memory (Gilles Peskine)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Jul 2020 14:42:33 +0000 (UTC)
From: "dany_banik2000(a)yahoo.com" <dany_banik2000(a)yahoo.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: [mbed-tls] Problem with decrypt aes 128 in ecb mode. HELP ME!
Message-ID: <1371131400.5486983.1595428953399(a)mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
I developed a server application that obtains the data from a dht11 sensor, I encrypt it with aes 128 and publish it on the server. The client application makes a request to the server, and I would like to decrypt the answer.
When I want to display decrypted message, it shows garbage
The message retrieved from the server is in hex. I think that must to convert hex in binary, but i don’t know how can do it…
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.trustedfirmware.org/pipermail/mbed-tls/attachments/20200722/a5…>
------------------------------
Message: 2
Date: Wed, 22 Jul 2020 17:10:18 +0200
From: Gilles Peskine <gilles.peskine(a)arm.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] SSH client sample
Message-ID: <4a7265ac-7b3e-33ef-7222-4cd29c3cda08(a)arm.com>
Content-Type: text/plain; charset=windows-1252
Hi Christie,
Libssh2 (https://github.com/libssh2/libssh2) supports Mbed TLS.
I've never used it or investigated it, so I can't vouch for it, I just know that it's there.
--
Gilles Peskine
Mbed TLS developer
On 21/07/2020 18:40, Christie Su via mbed-tls wrote:
>
> Hi,
>
> �
>
> I am using FRDM-K64F with LWIP+mbedTLS for our control system. Now, I
> want to develop the SSH client(or telnet 22) to access my SSH server.
>
> �
>
> Could you give me some indications how to do it? Or do you have any
> sample project?
>
> �
>
> Thanks,
>
> �
>
> Christie
>
>
------------------------------
Message: 3
Date: Wed, 22 Jul 2020 17:34:44 +0200
From: Gilles Peskine <gilles.peskine(a)arm.com>
To: mbed-tls(a)lists.trustedfirmware.org
Subject: Re: [mbed-tls] patches for low memory
Message-ID: <152f6571-6972-8262-c38d-d200dcc7c0b7(a)arm.com>
Content-Type: text/plain; charset=utf-8
Hi Nick,
A TLS stack in 6kB of RAM sounds impressive, congratulations!
We'd certainly be interested in all the improvements you can contribute.
The process is documented in CONTRIBUTING.md (https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). I just need to warn you that the limiting factor is reviewers' time. For a significant contribution, it may take a while before the Mbed TLS team can look at it in detail. Small patches are usually easier than large
ones: if something only takes half an hour to review, someone will probably do it when they're stuck on some other task. If a review takes several days, it needs to be scheduled.
It would probably be better to discuss the general nature of the changes on this mailing list first. Is a new compilation option needed? Is an API change needed? What is the risk that the change might break existing code? How is the new code tested? etc.
Which version of Mbed TLS have you been using? We've made a few changes that are of interest to low-memory platforms recently, such as the option MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH to resize SSL buffers after the handshake (new in 2.22).
I don't know what the issue with the incoming SSL packet header length could be. If you could give precise steps to reproduce the issue, this would be very helpful. Eventually we'd want to construct a test in tests/ssl-opt.sh for this.
--
Gilles Peskine
Mbed TLS developer
On 17/07/2020 21:00, Nick Setzer via mbed-tls wrote:
>
> Hi, I have been working with Mbed TLS for the last 6 months in an
> extremely low memory use case. This library has been an absolute joy
> to work with because of how flexible it is. I have an interesting use
> case with how little RAM I have to work with (around 6kb on one
> microprocessor) and I have made some changes that I thought would be
> of interest. I'm not sure if I should submit them as a single
> changeset or a set of changes. I'll describe the changes and if there
> is interest I can clean them up for submission.
>
> The first change that I made was for a scenario with two
> microprocessors communicating over a UART. I was already using TLS
> offloading so that the private key was on one processor (with only 6kb
> of RAM free) and the SSL context stored on the other. I required
> generating a CSR and thus made some changes to the CSR code to be able
> to generate the CSR using a similar private key offloading strategy.
>
> I found an issue with downloading firmware for OTA from openssl web
> servers. This is a little tricky to describe. The server was not
> responsive to requests for reducing the max fragment length, which
> forced me to use MBEDTLS_SSL_MAX_CONTENT_LEN set to 16384. But I
> needed to have multiple ssl sessions open for other activities and did
> not have enough RAM to hold multiple large buffers. I have made a set
> of changes to allow setting the content length when the ssl context is
> initialized, as well as setting different IN and OUT content lengths
> to save memory. This change allowed me to set up one session with 16kb
> for the IN content length, and then 4kb for OUT content length, while
> a second session could use 2kb for a total of 24kb instead of 64kb.
>
> Related to the openssl issue, I found that the incoming ssl packet
> header length can sometimes be 8 or 16 bytes larger than expected
> depending on which AES method is selected. I'm not actually sure what
> the best way to solve this is. One way may be to change
> MBEDTLS_SSL_HEADER_LEN from 13 to 29 bytes. However I ended up solving
> it by adding 16 to both MBEDTLS_SSL_IN_BUFFER_LEN and
> MBEDTLS_SSL_OUT_BUFFER_LEN. This way I could handle the larger ssl
> header as well as receive the content body.
>
> If these three changes sound interesting I can start work on cleaning
> up the code to be less specific to my company and then submit the
> changes. Also I would like to know if there is any process I should be
> following when submitting these changes.
>
> Thanks,
>
> Nick Setzer
> SimpliSafe, Inc.
> 294 Washington Street, 9th Floor
> Boston, MA 02108
>
------------------------------
Subject: Digest Footer
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
------------------------------
End of mbed-tls Digest, Vol 5, Issue 15
***************************************
