- mbed-tls - lists.trustedfirmware.org

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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 8 months

1
0
0 0

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

by Manuel Pegourie-Gonnard

Hi again, In the first email of the thread I tried giving a fair exposition of the question, now I'm going to give my personal opinion. Similarly to what I suggested for timing.c, I'm inclined to remove net.c as such, move most of its content (net_bind(), net_accept(), etc.) out of the library (most probably into a new file in programs/ssl, shared by SSL examples), and keep in the library only the 3 functions that can be used as SSL callbacks (and a supporting context type), but in a new module named for example ssl_io_sockets.c. This would also be similar to the other SSL modules that provide a reference/example implementation of some SSL callback but can easily be disabled (or jsut disregarded) in favour of a custom implementation for custom needs or unsupported platforms. Just like the current net_sockets.c, this new reduced module would probably only be supported on platforms with sockets, which is Posix platforms and Windows. Advantages include: - Reduce the amount of code and API surface in the library. Things like binding and accepting are hardly related to (D)TLS so there is little justification for having them in the library. Also, things in the library are bound by API stability rules which are sometimes a constraint. - It would clarify that we're not providing a general-purpose socket abstraction, as general socket management would be out of the library, and only the bits for plugging a socket into our SSL layer would be in the library. - (By the way currently net_sockets.h includes ssl.h, so it's already quite specific to our SSL module rather than generic, but moving the remaining bits of it into the SSL namespace would make that clearer.) - User would still have the convenience (on supported platforms) of ready-for-use callbacks. If you have an application already working with sockets without TLS, then we provide all the bits needed to turn that into an application using TLS on top of those sockets. I think that would be a good compromise between convenience for users, and reduced surface for the library. Regards, Manuel.

5 years, 8 months

1
0
0 0

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

by Hanno Becker

Hi, I support this. Could certs.c live in `tests/data_files`? We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past. Best Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Manuel Pegourie-Gonnard via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Monday, April 20, 2020 10:49 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [mbed-tls] 3.0 plans - move certs.c out of the library Hi all, In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library? [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`. These are used in the following places: - in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509. Reasons include: - Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway. - Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production. If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well! Regards, Manuel. -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls 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, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls