- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Random Number Generator module in mbed TLS

by Hanno Becker

Hi, Mbed TLS establishes variable-length access to random data in a three step fashion: 1) At the bottommost layer, there is a variable number of entropy sources external to the library. Such sources are supposed to provide some true randomness, though the exact amount of entropy they contain isn't yet specified (at least to my knowledge). 2) Mbed TLS' entropy module mixes those entropy sources into a single source of randomness. In contrast to the entropy sources themselves, the idea here is that, ideally, the data obtained from the entropy module has full entropy. This is achieved by (a) accumulating random data from available entropy sources and depending on the amount of entropy each of them offers, and (b) 'mixing' them by a application of hash functions. 3) Based on true randomness, Mbed TLS' provides two implementations of pseudo random number generators: CTR-DRBG and HMAC-DRBG. Those build on top of an entropy context and expand the underlying randomness as standardized in NIST SP 800-90. Applications should use the PRNGs from step 3) as their actual source of randomness, and not directly hook into the underlying TRNGs. Take a look at the example programs such as `ssl_client2` or `ssl_server2` to see how this works practically. Also see https://tls.mbed.org/kb/how-to/add-a-random-generator. Now specifically to your question: You should register your STM32 hardware entropy as an entropy source via `mbedtls_entropy_add_source()` but not (need) to change anything else in your code. In particular, steps 2) and 3) above are entirely independent of the exact source of true randomness. Hope this helps, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of ROSHINI DEVI via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, April 28, 2020 6:06 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS Hello, Can anyone confirm this? Its urgent. Thanks On Fri, Apr 17, 2020 at 4:50 PM ROSHINI DEVI <roshinilachi(a)gmail.com<mailto:roshinilachi@gmail.com>> wrote: Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 5 months

1
0
0 0

Random Number Generator module in mbed TLS

by ROSHINI DEVI

Hello, Is there any random number library available in mbedTLS? Right now, I am using hardware entropy in STM32 boards. If hardware platform changes and if there is no hardware entropy present, then again we need to redefine the API. Thanks

5 years, 5 months

1
1
0 0

Edwards curve support (#3245): fixing mbedtls_ecp_get_type

by Aurelien Jarno

Hi all, I have submitted PR#3245 in order to add Edwards curves support to Mbed TLS, with the eventual goal to add support for the EdDSA algorithm. There are still a few things to fix that require discussion. Let's start the discussion with the first one. Adding a new curve type requires to add a new entry to the mbedtls_ecp_curve_type enum. The curve type used by a group is returned by the mbedtls_ecp_get_type function. It currently uses the coordinates type of the base point to determine the curve type. Montgomery curves are lacking the y coordinate, and the Short Weierstrass curves use the three x, y and z coordinates. The Edwards arithmetic implementation in this PR uses the projective coordinates. As such it also uses the x, y and z coordinates and this gives no way to differentiate a Short Weierstrass from an Edwards curve. I have currently implemented that by checking if the curves are the Ed25519 or Ed448 ones using the group id [1]. I am not sure it's very clean and it won't scale if more curves are added later. Another alternative would be to add another entry to mbedtls_ecp_group to hold the curve type. What do you think is the best option? Any other idea? Thanks, Aurelien [1] https://github.com/ARMmbed/mbedtls/pull/3245/commits/aa20cf122a1a54cfa23624… -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien(a)aurel32.net http://www.aurel32.net

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Development environment: minimum tool versions

by Steffan Karger

Hi, I maintain OpenVPN-NL (https://openvpn.fox-it.com), which uses mbedtls as it's crypto library. On 24-04-2020 00:25, Gilles Peskine via mbed-tls wrote: > 1. Is there any interest in the community for making sure that the build > keeps (or starts) working on RHEL 6? Yes, we support RHEL6 until it's retirement (30 November 2020). > 2. Is there any interest in the community for making sure that the build > keeps working on Ubuntu 16.04? Yes, we support all Ubuntu LTS versions until their standard support ends (April 2021 for 16.04). > 3. Are there any other "old" platforms that we should consider? All Debian and SLES versions that are still in regular maintance (ie, not including any "extended security maintenance" support). It would be nice if it's at least possible to build mbedtls on/for these platforms until they go out of regular support. Preferably with their default packages compilers. SLES/RHEL are the most demanding, with their 10 year support cycle. Thanks, -Steffan

5 years, 5 months

1
0
0 0

Re: [mbed-tls] RSA key generation issue

by Gilles Peskine

Hi Nazar, On 24/04/2020 10:22, Nazar Chornenkyy via mbed-tls wrote: > > On the PSoC6 device we are using mbedtls_rsa_gen_key function with a > good hardware TRNG passed FIPS 140-2 verification. > > This function verifies generated random pair and requests new pair if > they don’t follow FIPS 186-4 criteria. > > The number of verification loops is between 1 and 6 in worst case. > > Is it expected behavior? > > The arithmetic of one loop takes a lots of time. > > How can we improve the random number to have always pass FIPS 186-4 in > a one loop? > I'm not sure what you're doing. Are you calling mbedtls_rsa_gen_key() multiple times and rejecting the key if it doesn't pass additional checks? Or are you just calling it once? As far as I know, mbedtls_rsa_gen_key() follows the procedure described in FIPS 186-4 (which is compatible with previous versions of FIPS 186), and no additional checks should be needed. If you're calling it once and observing that it tries multiple values of p and q before finding a suitable one, this is expected behavior. There's no way to "improve" the random numbers to make it faster: the probability that a pair of (probabilistic) primes can work together as an RSA key is less than 1. I don't know the math off the top of my head, but 1–6 tries seems reasonable. Key generation is the slowest of the RSA operations. If that's a problem in your application, consider using elliptic curve cryptography instead. ECC has very fast key generation, faster private key operations (signature, decryption) than RSA, and smaller keys. The main benefit of RSA is that public key operations (verification, encryption) are faster. -- Gilles Peskine Mbed TLS developer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 5 months

1
0
0 0

Development environment: minimum tool versions

by Gilles Peskine

Hello, I'm starting this thread to get input from the community about what versions of compilers and other build tools Mbed TLS should support. We of course strive to remain compatible with the latest versions, so this discussion is about support for older versions. We currently don't really have an official version range for the build dependencies of Mbed TLS: * C compilers (GCC, Clang, Arm Compiler, IAR, Visual Studio) * Build tools (GNU make, CMake) * Scripting tools (shell, Perl, Python) In practice, for the past three years or so, most of our continuous integration has been running on Ubuntu 16.04, so we mostly test with GCC 5.4.0, Clang 3.8, GNU make 4.1, CMake 3.5.1 and Python 3.5. (For shell and Perl, even pretty ancient version should work.) For Arm Compiler (armcc/armclang) and IAR, we use the same version as Mbed OS. On Windows, we currently test Visual Studio 2013, 2015 and 2017, as well as a version of Mingw that's changed more quickly than most of the rest of our CI. We also run some tests on FreeBSD (a bit more recent that the Ubuntu machines). The top-level CMakeLists.txt has conditionals that detect much older versions of CMake, GCC and Clang, but we haven't tested those in ages and we don't really know if, for example, the library still builds with CMake 2.8 and GCC 4.2. As part of the move of the project from Arm to Trusted Firmware, we'll change our CI infrastructure, and this may or may not mean we end up testing with different versions. In https://github.com/ARMmbed/mbedtls/issues/2896 I looked at the software versions in some common "slow updating" operating systems: RHEL/Centos, Ubuntu LTS. 1. Is there any interest in the community for making sure that the build keeps (or starts) working on RHEL 6? 2. Is there any interest in the community for making sure that the build keeps working on Ubuntu 16.04? 3. Are there any other "old" platforms that we should consider? 4. Should we consider older compilers (maybe some platforms are stuck with older versions of GCC)? 5. On Windows, what's the oldest version of Visual Studio we should keep compatibility with? -- Gilles Peskine Mbed TLS developer IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 5 months

1
0
0 0

RSA key generation issue

by Nazar Chornenkyy

Hi I found this email on ARM MBED support forum. Could you help to resolve our issue? On the PSoC6 device we are using mbedtls_rsa_gen_key function with a good hardware TRNG passed FIPS 140-2 verification. This function verifies generated random pair and requests new pair if they don't follow FIPS 186-4 criteria. The number of verification loops is between 1 and 6 in worst case. Is it expected behavior? The arithmetic of one loop takes a lots of time. How can we improve the random number to have always pass FIPS 186-4 in a one loop? Thanks Nazar This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 5 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move net.c out of the library

by Gilles Peskine

Like with timing (see my message in the timing thread, https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000061.html), I have a strong preference for the library to be usable out of the box on typical platforms. This means keeping the abstractions that are currently in the net_sockets module, or similar abstractions. This doesn't mean keeping the net_sockets module as such: these abstractions could be in platform.c. I lean towards having a platform_posix.c and a platform_windows.c (and any other we care to support), chosen at build time based on the target platform. I'm not sure exactly what they should look like. In particular, if you have an embedded platform that's sort of POSIX-like, but doesn't have every POSIX feature and does a few differently, should you be able to customize platform_posix.c through #defines, or should you copy it and modify it to suit your platform? -- Gilles Peskine Mbed TLS developer On 20/04/2020 11:52, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ] > > Currently the SSL/TLS library includes a module called net_sockets.c (formerly > net.c), enabled by default in config.h (but disabled by config.py baremetal), > that contains some networking functions based on POSIX or Windows sockets, > including functions suitable for use as I/O callbacks with our SSL/TLS > modules. > > Those functions are used only in example/testing programs, but nowhere in the > library itself. > > In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, > we're considering removing (parts of) this module from the library, and > moving its parts to a variety of other places, such as example programs (or > a library/file shared by them, like the current query_config mechanism). > > Reasons for removing this module from the library include: > > - overall the module is less portable and perhaps of lesser quality than the > rest of the library > - it's currently entirely untested on Windows (despite being very > platform-specific) > - there are often confusions about whether the module is meant to be a > general-purpose networking library, or just provide basic support for our > example and test, as well a simple prototypes > - it's not our core area of expertise, let's do one thing and to it well > > Reasons for keeping (parts of) it in the library include: > > - having mbedtls_net_recv{,_timeout}() and mbedtls_net_send() available right > in the library makes it easier to test and develop prototype > - this module is listed as a component in our high-level design document [2], > so perhaps removing it from the library can be seen as a bigger change? > > [2]: https://tls.mbed.org/high-level-design > > What do you think? Should we remove the entire module from the library, keep > it all, or just keep some parts? In that case, which parts and where? > > Regards, > Manuel. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 6 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Gilles Peskine

I have a strong preference for the library, the tests and companion programs to build out of the box on officially supported platforms. On platforms that don't work out of the box, users should be able to drop in platform support code in the form of #defines or extra modules to link with. Ok, we don't have an official list of supported platforms. But inasmuch as we do have officially supported platforms, they include Linux and other modern Unix-like or POSIX environments, Windows, and Mbed OS. Mbed OS is a special case because Mbed TLS is part of the build tree there, so the mbedtls tree doesn't have to contain Mbed OS support. This doesn't mean that the library should have a timing module. I think the timing wrappers that the library needs, i.e. mbedtls_timing_{get,set}_delay, should be in platform.c. For platform features that are only used by test or sample programs, I think we should have a separate platform support file, and separate #defines so that you can build the library even if you can't build all the programs. For example, it makes sense to build DTLS support without having the timing functions used by the benchmark program. -- Gilles Peskine Mbed TLS developer On 21/04/2020 10:46, Manuel Pegourie-Gonnard via mbed-tls wrote: > Hi all, > > So personally I'm quite strongly inclined to remove timing.c from the > library, and move most of its content elsewhere, with one possible > exception: > >> - mbedtls_timing_set_delay() and mbedtls_timing_get_delay() are an example >> implementation (only for Unix and Windows) of timer callbacks for DTLS, only >> used in programs/ssl/*.c > Since timer callbacks are a hard requirement for using DTLS, and it seems > quite desirable to be able to support DTLS out of the box at least on > some platforms, I was thinking this pair of function (and the associated > context type) could be kept in the library, in a new module that would > be called something like ssl_dtls_timer.c. > > This would be somewhat similar to ssl_cookies.c, ssl_tickets.c and > ssl_cache.c: they all provide implementations of callbacks that can be > used with the main SSL/(D)TLS module, but users are obviously free to > compile them out and use their own implementation if the one we provide > does not meet their needs. > > As it happens, all three of these support modules work best if > MBEDTLS_HAVE_TIME is defined, but can work without it. > > For the new ssl_dtls_timer.c I'm suggesting, the situation would be > different: the module could have a hard dependency on MBEDTLS_HAVE_TIME, > but work better on selected platforms (say, C11, POSIX and > Windows) where we know how to access sub-second timing information. (Or > alternatively, have a hard dependency on C11-or-Posix-or-Windows.) > > For the record, mbedtls_ssl_conf_handshake_timeout() accepts timeout > values in milliseconds, but recommended values for use over the general > internet start at 1 second: > https://tools.ietf.org/html/rfc6347#section-4.2.4.1 > So it might make sense to provide this module even when we only have > second resolution - we'd just have to work out how the timer function > would behave when passed sub-second values. (My first thought it > rounding up to the next second would be quite OK.) > > What do you'all think? Personnally, I don't have a strong opinion > between the three following options, though I have a slight preference > for the first one: > > 1. Provide ssl_dtls_timer.c in the library with hard dep on HAVE_TIME > and enhanced features with C11/Posix/Windows. > 2. Provide ssl_dtls_timer.c in the library with hard dep on > C11/Posix/Windows. > 3. Move it all out of the library and let the thing live somewhere under > programs/ as it's only used by example/testing programs. > > Note though that we could also choose to go with option 3 for Mbed TLS > 3.0, see how it goes, and later switch to option 2 or 1 if we want, as > adding modules can be done at any time. (In the same vein, we could > start with 2 and switch to 1 at any time as well.) > > Regards, > Manuel. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 6 months

1
0
0 0

Re: [mbed-tls] 3.0 plans - move timing.c out of the library

by Manuel Pegourie-Gonnard

Hi, > [I'm assuming didn't mean to reply on the list and not just to me, so I'm replying on the list.] Oops, I misinterpreted the information presented by my mail client, you did reply on the list. Sorry for the noise (and for breaking the thread by not replying to the correct email.) Manuel.

5 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls