Hi All,
I appreciate I'm coming very late to this discussion, but I want to make a point and suggestion.
The performance of the asymmetric functions is less than ideal, and whilst I think we can all agree that the ECC code should be rewritten at some point to be more competitive, one of the issues with the performance is that the MPI code uses malloc() a lot. There are competing crypto libraries out there that are faster and use a smaller RAM footprint and don't use dynamic memory allocation at all.
Our memory allocation code is also kind of slow, and has a primitive and simplistic design of a linked list.
These are very similar points to those Manuel was making to remove the feature in the first place - however - short of investing the time in rewriting the asymmetric functions, what we could do as a quick fix is to replace the existing memory code with a block allocation scheme - which should be much faster, speed up the asymmetric functions (in theory), avoid fragmentation, be more deterministic, and a better fit for embedded applications. That could then become the basis of the library for other projects too.
I wouldn't mind contributing such a feature, as I had to write something very similar last week anyway.
If I do it - will you accept it?
Kind regards
Simon
On 09/04/2020, 12:07, "mbed-tls on behalf of Dan Handley via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote:
Hi
There has already been some discussion about a shared C standard library implementation, at least for TF-A and TF-M. So far there's been general agreement that this is a good idea but no actual commitment from anyone to make this happen, since each project is reasonably happy with what they've got.
Regarding MBEDTLS_MEMORY_BUFFER_ALLOC_C, TF-A at least enables this so removing this from the codebase would be an issue there. Memory allocators are probably not the core expertise of other Trusted Firmware projects either but it needs to be if they're going to use them!
I propose that we move this allocator into a new shared TrustedFirmware.org standard C library project and work with the other projects to ensure it has the correct initial maintainers. This will probably have to be driven by the maintainers of whichever project is most motivated to make this happen. It sounds like that could be Mbed TLS and this will need to be done before any separation of the PSA Crypto implementation. In the short term, as we move C stdlib functionality out of the other projects and into this new project, we will need to support multiple implementations of some functions. Eventually we should move towards a common implementation, and I agree we should look at what security-oriented implementations are already available.
I also agree it would make sense for Mbed TLS to not use the toolchain-provided stdlib implementation by default, but only once it uses a default implementation it trusts.
Regards
Dan.
> -----Original Message-----
> From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of
> Ronald Cron via mbed-tls
> Sent: 09 April 2020 08:47
> To: mbed-tls(a)lists.trustedfirmware.org
> Subject: Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code
> base
>
> Hi, I think this is related to the more general need for an implementation of
> the C standard library for trusted firmware projects. As far as I know TF-A
> and TF-M don't use the standard library provided by compilation toolchains.
> The rationale is to have complete control over the trusted firmware code.
> Currently they both have their own partial implementation of the parts of the
> C standard library they need.
>
> This memory_buffer_alloc.c module in question here is another partial
> implementation of the C standard library. Currently TF-A and TF-M don't
> use/provide dynamic memory allocations but PSA-FF explicitly mentions that an
> SPM implementation may support dynamic memory allocation. Thus it is possible
> that TF-M at some point consider providing dynamic memory allocation support.
>
> All of this to say that a possible way forward may be to remove
> memory_buffer_alloc.c from the code base when there is a C standard library
> implementation common to trustedfirmware.org projects (is there already a
> security oriented open source implementation out there ?).
>
> In Mbed TLS, it would also make sense to me to, by default, not use C
> standard libraries provided by compilation toolchains
> (MBEDTLS_PLATFORM_NO_STD_FUNCTIONS defined by default).
>
> Thanks, Ronald.
>
>
> -----Original Message-----
> From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of
> Manuel Pegourie-Gonnard via mbed-tls
> Sent: 08 April 2020 12:42
> To: mbed-tls(a)lists.trustedfirmware.org
> Cc: nd <nd(a)arm.com>
> Subject: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code
> base
>
> Hi all,
>
> In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]:
> should we remove memory_buffer_alloc.c from the code base?
>
> [1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/
>
> Currently the crypto library includes a module called memory_buffer_alloc.c,
> disabled in the default build (config.h option MBEDTLS_MEMORY_BUFFER_ALLOC_C),
> which provides implementations of calloc() and free() based on a user-
> provided buffer (which could be static or on the stack), suitable for use in
> the rest of the crypto, X.509 and TLS libraries as replacements to the
> standard functions.
>
> In addition to providing replacement calloc() and free(), the module also
> offers some facilities for measurement and debugging.
>
> We're considering dropping this module and removing it from the code base
> entirely for the following reasons:
>
> - Memory allocators are not our core area of expertise.
>
> - This allocator is pretty basic and has a large allocation overhead. For
> example for ECC computations, the overhead can be as large as the actual
> memory used.
>
> - Using this allocator also tends to slow things down, so we don't run many
> tests with it enabled.
>
> - In the future when we split between PSA Crypto on one side and Mbed TLS and
> X.509 on the other, it's unclear on which side this allocator should fall.
> Which can be taken as a sign that it doesn't really belong here.
>
> On the other hand, we're hesitating for the following reasons:
>
> - We know from bug reports and questions that some people are using it.
>
> - Unlike other modules we'd like to drop, there isn't a strong security
> incentive to dropping this allocator, it's merely a matter of how we spend
> our maintenance resources.
>
> What do you think? Should we keep maintaining this allocator as part of Mbed
> TLS? Should we drop it and focus on our core instead? If you're using this
> allocator, why did you pick it over other alternatives?
>
> 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.
> --
> 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.
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
On 25/04/2020 23:44, Steffan Karger via mbed-tls wrote:
> 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).
(…)
> 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.
>
All right, thanks for the feedback! I'm not going to promise that we'll
add RHEL 6 to our CI. (Of course, in TrustedFirmware, it can happen if
someone's motivated enough to contribute it and to keep maintaining it.)
But let's at least not knowingly break support for CMake 2.8 yet (or GNU
make 3.81 or older GCC and Clang but those are less likely to break).
I expect that it will remain possible to build the library *for* ancient
systems for a very long time, since all it really needs is a basic C
runtime. But the tooling to build the library, or at least to do
anything more than building the library (tuning the configuration,
building and running tests, etc.) is slowly modernizing (the
configuration script and the test building script have required Python 3
for a while now).
--
Gilles Peskine
Mbed TLS developer
Hello,
I am trying to do the ECDH shared secret computation using the mbedTLS library. I am referring to multiple examples such as ecdh_curve25519.c<https://github.com/ARMmbed/mbedtls/blob/development/programs/pkey/ecdh_curv…> and ecdh_main.c<https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/se/s…>.
In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1 in the bootloader itself. So in the application firmware, I would like to do generate a shared secret from here on and preserve it for future use.
The following is the steps that I do:
1. Create a new client context, entropy context, ctr_drbg context variables.
2. use mbedtls_"respective"_init() to initalize all the three variables
3. Seed a random number using mbedtls_ctr_drbg_seed() function.
4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load()
5. Then use mbedtls_mpi_lset() to set Qp.Z =1
6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65);
7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using
mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ?
8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z.
Questions:
1. Do I need to generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv key and pub key as service pub key?
2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I extract these two values from a public key? Do I need to separately initialize them?
Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. They do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case.
Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary_le functions?
Thanks so much for your help in advance!
Thanks,
Abhilash
From: Abhilash Iyer
Sent: Monday, April 27, 2020 11:25 AM
To: mbed-tls(a)lists.trustedfirmware.org
Subject:
Hello,
I am trying to do the ECDH shared secret computation using the mbedTLS library. I am referring to multiple examples such as ecdh_curve25519.c<https://github.com/ARMmbed/mbedtls/blob/development/programs/pkey/ecdh_curv…> and ecdh_main.c<https://github.com/SiliconLabs/peripheral_examples/blob/master/series2/se/s…>.
In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1 in the bootloader itself. So in the application firmware, I would like to do generate a shared secret from here on and preserve it for future use.
The following is the steps that I do:
1. Create a new client context, entropy context, ctr_drbg context variables.
2. use mbedtls_"respective"_init() to initalize all the three variables
3. Seed a random number using mbedtls_ctr_drbg_seed() function.
4. load the P256 elliptic curve in client context using mbedtls_ecp_group_load()
5. Then use mbedtls_mpi_lset() to set Qp.Z =1
6. Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65);
7. Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using
mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ?
8. Then I use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z.
Questions:
1. Do I need to generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)? And then set pvtkey as device priv key and pub key as service pub key?
2. I see that ctx_cli.Q has two components, Q.x and Q.y. How do I extract these two values from a public key? Do I need to separately initialize them?
Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. They do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case.
Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary_le functions?
Thanks so much for your help in advance!
Thanks,
Abhilash
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Perfect!
Thanks everyone for your assistance.
On Tue, Apr 28, 2020 at 1:48 PM Janos Follath via mbed-tls <
mbed-tls(a)lists.trustedfirmware.org> wrote:
> Hi,
>
>
>
> Hanno described perfectly how it works and I just would like to add a
> single remark. You mentioned that some of your platforms don’t have a
> hardware entropy source. In cases like that, depending on your threat model
> you might need to use the MBEDTLS_ENTROPY_NV_SEED feature to achieve
> security.
>
>
>
> (This uses a stored secret value as a seed and on embedded systems without
> a hardware entropy source it is more secure against a remote adversary than
> trying to collect the entropy from the environment. On systems like that
> NV_SEED can have an edge against physical attackers – compared to
> attempting to collect entropy from the environment – if the seed is stored
> in secure storage/internal flash.)
>
>
>
> Regards,
>
> Janos
>
>
>
> *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf
> of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
> *Reply to: *Hanno Becker <Hanno.Becker(a)arm.com>
> *Date: *Tuesday, 28 April 2020 at 07:55
> *To: *"mbed-tls(a)lists.trustedfirmware.org" <
> mbed-tls(a)lists.trustedfirmware.org>, ROSHINI DEVI <roshinilachi(a)gmail.com>
> *Subject: *Re: [mbed-tls] Random Number Generator module in mbed TLS
>
>
>
> 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>
> 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.
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
Hi,
Hanno described perfectly how it works and I just would like to add a single remark. You mentioned that some of your platforms don’t have a hardware entropy source. In cases like that, depending on your threat model you might need to use the MBEDTLS_ENTROPY_NV_SEED feature to achieve security.
(This uses a stored secret value as a seed and on embedded systems without a hardware entropy source it is more secure against a remote adversary than trying to collect the entropy from the environment. On systems like that NV_SEED can have an edge against physical attackers – compared to attempting to collect entropy from the environment – if the seed is stored in secure storage/internal flash.)
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Hanno Becker <Hanno.Becker(a)arm.com>
Date: Tuesday, 28 April 2020 at 07:55
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>, ROSHINI DEVI <roshinilachi(a)gmail.com>
Subject: Re: [mbed-tls] Random Number Generator module in mbed TLS
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.
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.
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.
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.
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.
Hi Torsten,
[I'm assuming didn't mean to reply on the list and not just to me, so I'm
replying on the list.]
> On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote:
>> For reference, this module includes the following functions, which are used
>> in the following places:
>>
>> - mbedtls_timing_hardclock() implements cycle counting (on selected
>> architectures, not including M-class), used only in
>> programs/test/benchmark.c
>
> I used mbedtls_timing_hardclock() for my own benchmarking experiments on
> Linux and Windows, but couldn't get it to run on the target machine. So
> I've use my own ms counter instead. So, it could be easily removed as
> part of the library.
>
Good to know, thanks for sharing this data point.
> Question: How do you want to do the benchmarking instead? With the same
> code, but outside the library?
>
Yes, I was thinking that the functions that are only used in benchmark.c
could be defined in benchmark.c, and the functions that are only used in
udp_proxy.c could be defined in udp_proxy.c.
(Or actually for the latter, we might want to start using them in
ssl_client2.c and ssl_server2.c as well, as including millisecond
timestamps in the debug output would be usefull to debug some issues. In
that case, we'll probably put those functions in a new file, used by
udp_proxy, ssl_client2 and ssl_server2 (just like query_config.c is
currently used by ssl_client2, ssl_server2 and
query_compile_time_config).)
Regards,
Manuel.
Hi Torsten,
> this will be a long mail. Sorry for that.
>
On the contrary, thank you so much for this extensive and well though-out
feedback, that's very helpful!
I'll try to complement Gilles's reply, and skip the points he already answered
unless I have something to add, as I'm generally in full agreement with what
he wrote.
> 3. For certification and evaluation purposes I need some test vectors
> for each crypto function on target. While I know about the
> comprehensive self-test program I'm now talking about built-in
> functions like mbedtls_sha512_self_test(), etc to be enabled with
> #define MBEDTLS_SELF_TEST.
>
> These self-tests are very different in coverage. For SHA-384 and
> SHA-512 they are fine, for HMAC-SHA-384 and HMAC-SHA-512 I couldn't
> find any as well as for HKDF-HMAC-SHA-256 (in RFC 5869) or
> HKDF-HMAC-SHA-384/512 (official test vectors difficult to find).
> AES-CTR and AES-XTS are only tested with key length 128 bit, not with
> 256 bit. AES-CCM is not tested with 256 bit and even for 128 bit,
> the test vector from the standard NIST SP 800-38C with long
> additional data is not used.
> The builtin self-test for GCM is the best I've seen with mbedtls:
> all three key lengths are tested as well as the IUF-interface and
> the comfort function. Bravo!
>
Indeed so far we don't have clear guidelines on self-test functions, and we
should try to have more consistency here. Since this is incremental,
backwards-compatible improvements, it can be done at any time (unlike some API
improvements that can only be done when preparing major versions).
Contributions in this area are certainly welcome!
> 7. While at Elliptic Curve Cryptography: I assume that some of you
> know that projectives coordinates as outer interface to ECC are
> dangerous, see David Naccache, Nigel P. Smart, Jacques Stern:
> Projective Coordinates Leak, Eurocrypt 2004, pp. 257–267.
Yes, and as it happens this was revisited recently by researchers, and brought
back to our attention:
https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advi…
> you have Jacobian coordinates, i.e. projective coordinates, as outer
> interface. In the comment, its is noted that only the affine part is
> used, but can this be assured? In all circumstances?
>
In practice, I'm pretty confident this is the case, because both
ecp_normalize_jac() and ecp_normalize_mxz() set Z to 1, these functions are
always called before returning data, and if we forgot to call those functions,
we'd get incorrect X and Y coordinates and fail unit test and interop tests.
But as a matter of principle, I agree that exposing Jacobian coordinates in
the API was a poor decision. Fortunately, we already intended to start phasing
out the existing ECP interface in 3.0 (to which extend exactly is still to be
discussed), and in the future is should be fully removed in favour of the PSA
Crypto API, which doesn't have this problem.
> 8. In my personal opinion the definition
> [...]
> mbedtls_ecp_keypair;
>
> is dangerous. Why not differentiate between private and public key
> and domain parameters?
I agree, and I think it's a generally accepted opinion in the crypto
implementation community that private and public keys should be clearly
distinguished from one another, for example by using distinct types (in typed
languages).
This is by the way a long-standing problem that existed in the RSA module from
the start, and when ECC was added it followed a similar pattern.
Again, I think the transition of the PSA Crypto API is going to be the answer
here, as it will provide much cleaner key management.
> 9. Regarding ECC examples: I found it very difficult that there isn't
> a single example with known test vectors as in the relevant crypto
> standards, i.e. FIPS 186-4 and ANSI X9.62-2005, with raw public
> keys. What I mean are (defined) curves, public key value Q=(Qx,Qy)
> and known signature values r and s. In the example ecdsa.c you
> generate your own key pair and read/write the signature in
> serialized form. In the example programs/pkey/pk_sign.c and
> pk_verify.c you use a higher interface pk.h and keys in PEM format.
>
> So, it took me a while for a program to verify (all) known answer
> tests in the standards (old standards as ANSI X9.62 1998 have more
> detailed known answer tests). One needs this interface with raw
> public keys for example for CAVP tests, see The FIPS 186-4 Elliptic
> Curve Digital Signature Algorithm Validation System (ECDSA2VS).
>
> 11. In the moment, there is no single known answer tests for ECDSA
> (which could be activated with #define MBEDTLS_SELF_TEST). I
> wouldn't say that you need an example for every curve and hash
> combination, as it is done in ECDSA2VS CAVP, but one example for
> one of the NIST curves and one for Curve25519 and - if I have a
> wish free - one for Brainpool would be fine. And this would solve
> #9 above.
>
I might be misunderstanding, but isn't the function
ecdsa_prim_test_vectors() in tests/suites/test_suite_ecdsa.function close to
what you're looking for? I mean, except for the fact that it's not in the
self-test function, and that it's using data from RFCs rather than from NIST
or ANSI?
But I agree this is a bit messy and could be made cleaner.
Also, if you ever feel like contributing your dream self-test function for
ECDSA as PR, this will be a very welcome contribution!
> 13. Feature request: Since it was irrelevant for my task (only
> verification, no generation) I didn't have a detailed look a your
> ECC side-channel countermeasures. But obviously you use the same
> protected code for scalar multiplication in verify and sign,
> right? Wouldn't it be possible to use Shamir's trick in
> verification with fast unprotected multi-scalar multiplication. In
> the moment, mbedtls_ecdsa_verify is a factor 4-5 slower than
> mbedtls_ecdsa_sign, while OpenSSLs verify is faster than sign.
>
Yes, this was done to save both on code size and developer time, but I agree
it's suboptimal for performance. As Gilles wrote, as a general rule we tend to
favour code size and security/maintainability over performance, but in that
instance if we provide an option for a verify-only ECDSA build (which I agree
we should), then we're likely to reach smaller code size by having a
standalone unprotected implementation of multi-scalar multiplication, so that
would probably be a great option: better performance _and_ smaller code.
Unfortunately we're already quite busy with other things, so this kind of
optimisation will probably have to wait for a bit more, but we're taking good
note of the suggestion and will try to implement it in the future.
Again, thanks for this comprehensive and useful feedback.
Regards,
Manuel.
On 20/04/2020 11:51, Manuel Pegourie-Gonnard via mbed-tls wrote:
> [ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ]
>
> Currently the crypto library includes a module called timing.c, enabled by
> default in config.h (but disabled by config.py baremetal), containing various
> functions related to timing (not to be confused with the time abstration
> present in the platorm module).
>
> 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).
>
> For reference, this module includes the following functions, which are used in
> the following places:
>
> - mbedtls_timing_hardclock() implements cycle counting (on selected
> architectures, not including M-class), used only in
> programs/test/benchmark.c
I used mbedtls_timing_hardclock() for my own benchmarking experiments on
Linux and Windows, but couldn't get it to run on the target machine. So
I've use my own ms counter instead. So, it could be easily removed as
part of the library.
Question: How do you want to do the benchmarking instead? With the same
code, but outside the library?
Torsten
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.
[ Context: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/ ]
Currently the crypto library includes a module called timing.c, enabled by
default in config.h (but disabled by config.py baremetal), containing various
functions related to timing (not to be confused with the time abstration
present in the platorm module).
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).
For reference, this module includes the following functions, which are used in
the following places:
- mbedtls_timing_hardclock() implements cycle counting (on selected
architectures, not including M-class), used only in
programs/test/benchmark.c
- mbedtls_timing_get_timer() is a millisecond counter (only for Unix and
Windows), used only in programs/test/udp_proxy.c
- mbedtls_set_alarm() is an abstraction of alarm() (only for Unix and
Windows), used only in programs/test/benchmark.c
- 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
Reasons for removing this module from the library include:
- overall the module is less portable and of lesser quality than the rest of
the library
- it's also very hard to test and we've lost a lot of time and energy to that,
with very limited success
- it doesn't really belong in libmbedcrypto
- 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:
- for mbedtls_timing_set_delay() and mbedtls_timing_get_delay(): they're
convenient to have for DTLS examples and prototyping, we could keep them in
some place in libmbedtls (not libmbedcrypto).
What do you think? Should we remove the entire module from the library, or
keep some parts? In that case, which parts and where should they live?
Regards,
Manuel.
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.
Hi all,
I would like to bring up the following:
(How) Shall the APIs for PSKs and TLS session resumption be modified in Mbed TLS 3.0?
The motivation for this question is the consolidation of PSKs, ticket-based resumption
and session-id-based resumption in TLS 1.3. Now, while there will be no TLS 1.3 support
in Mbed TLS 3.0 as it stands, I think it would be beneficial to make the API amenable
to TLS 1.3 as much as possible already now.
Finding the right API here is non-trivial, and I'll describe first how the
current API works and how TLS 1.2 and 1.3 differ, before making suggestions
on how the Mbed TLS 3 API might look like. The mail is therefore quite long,
but I hope you'll bear with me.
# Session Resumption in Mbed TLS 2.X
Recall how resumption works in Mbed TLS 2.X on the client:
1. Establish a connection as usual
2. Store established session for later re-use
`mbedtls_ssl_session_save()` saves connection parameters relevant for
session resumption in an instance of `mbedtls_ssl_session`.
Optional:
2.1: Serialize session for offline storage
2.2: Deserialize session
3. Loading a stored session
`mbedtls_ssl_session_load()` is called on the stored session after initialization
and before running the handshake via `mbedtls_ssl_handshake()`.
4. Connect using stored session
Run `mbedtls_ssl_handshake()` as usual.
To my knowledge, the following is transparent to the user:
* The means by which resumption is achieved, which can be either id- or ticket-based.
* Whether the session was resumed or not - there is a silent fallback to a full
handshake when session resumption is rejected by the server.
On the server, ticket- and id-based resumption are configured independently as follows:
- ID-based resumption is controlled via `mbedtls_ssl_conf_session_cache()`
- Ticket-based resumption is controlled via `mbedtls_ssl_conf_session_tickets_cb()`.
# PSKs in Mbed TLS 2.X
Coming to PSKs: First, recall that, under the hood, resumed connections establish
a master secret purely on the basis of a previous master secret, without resorting to
asymmetric crypto. The same is true for PSK-based connections, and this observation is
embodied in TLS 1.3 which, as mentioned, consolidates resumption and PSKs.
In TLS 1.2, though, PSKs and session resumption are different, and consequently
Mbed TLS handles them through a separate API `mbedtls_ssl_conf_psk()`, which
takes the PSK identifier and the PSK itself.
Side-question: Should this apply to the SSL configuration or the SSL context?
It seems to me that somebody might want to run multiple PSK-based
connections with different PSKs, but same configuration otherwise.
At the moment, this would require a configuration per connection.
Maybe this decision of what belongs at the level of the config
could be thoroughly discussed independently?
# PSKs in TLS 1.3
In TLS 1.3, all kinds of resumptions are hanlded ander the umbrella of PSKs:
The client offers PSK identities in its ClientHello, the server picks one or
leaves it, and the master secret for the connection is derived from the PSK
associated with the PSK identity.
Underlying this is some form of translation
`PSK-Identity -> PSK`
on the server which allows to derive the PSK from the PSK identity.
How this mapping is realized is entirely implementation-specific,
but it can take at least the following forms, giving back all forms
of session resumption:
- 'PSK Identity -> PSK' via database lookup:
This subsumes classical PSKs and ID-based resumption,
since the data necessary to resume a session is stored
on the server.
- 'PSK Identity -> PSK' via AEAD:
The PSK can be encoded in the PSK identity itself by using some
authenticated encryption of the PSK as the PSK identity, the key
for which resides on the server.
This subsumes Ticket-based resumption.
There are the following noteworthy differences, though:
1. In TLS 1.2, the server provides a 'PSK identity hint' and the
client picks a particular PSK identity. In TLS 1.3, the client
offers a _list_ of PSKs, and the server picks one or none.
2. In TLS 1.2, the server can issue only a single session ticket.
In TLS 1.3, the server can issue as many session tickets as
he wishes, and the client can use any of those for later
session resumption.
This has the following consequences for the API:
1. The PSK-configuration API must allow the configuration
of multiple PSKs on the client.
2. There must be a means to export more than one session ticket
for later resumption.
# API considerations for Mbed TLS 3.X
## Part 1: Load/Save API
In essence, keep the flow of `mbedtls_ssl_session_load/save()`,
but make the following adjustments. Whether the target structure
remains `mbedtls_ssl_session` and how it looks like internally
isn't relevant at this point and is up to discussion.
1. It must be possible 'save' a session multiple times, which
in TLS 1.3 amounts to exporting the tickets issued by the
server one-by-one.
This can be realized in a variety of ways, for example:
- Allow calling `mbedtls_ssl_session_save()` multiple
times, and modify its semantics from the idempotent
nature of Mbed TLS 2.X to iterating through the available
tickets, and returning an error when no more tickets
are available.
This has the benefit that it likely requires no code
change for users migrating from Mbed TLS 2.X, since
a change is needed only when an application stores
a single session multiple times, which could be done
by calling `mbedtls_ssl_session_save()` multiple times
before, while now one would need to call it once and
manually replicate the obtained session structure.
On the negative side, this wastes memory for applications
not interested in session resumption, or those that only
need a single ticket. We don't want the server to be able
to flood the client with arbitrarily many tickets.
- Allow registering a callback that's triggered whenever
a new ticket arrives.
The drawback of this is that it is larger deviation
from the Mbed TLS 2.X API. On the positive side, applications
that don't need tickets, or only need a limited number of
such, can simply drop further tickets and thereby prevent
allocating RAM for them.
2. It must be possible to 'load' multiple sessions, meaning
that the client should offer any of them to the server for
resumption.
## Part 2: Consolidation with PSK
Make it possible to setup an `mbedtls_ssl_session` (or whatever
it will be called) structure manually from an externally PSK
provisioned PSK, and allow loading this session for resumption
as above, via one of potentially many calls to `mbedtls_ssl_session_load()`.
There are multiple variants to this, for example:
1. Make `mbedtls_ssl_session` transparent so users can build
it manually by filling the respective fields.
2. Provide a helper API to build a session from a PSK.
The old API `mbedtls_ssl_conf_psk()` can then be _derived_ from
this for convenience, building a session from the provided PSK
and loading it, in a single API.
Before going into further details and making the mail even
longer: What do you think of this approach? Do you see
alternatives?
Best,
Hanno
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.
