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
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
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
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.
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.
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.
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.
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.
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.
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.
