- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] 3.0 plans: remove memory_buffer_alloc.c from the code base

by Simon Butcher

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

5 years, 1 month

1
0
0 0

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

by Gilles Peskine

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

5 years, 1 month

1
0
0 0

ECDH Computation on STM32 platform

by Abhilash Iyer

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

5 years, 1 month

1
0
0 0

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

by ROSHINI DEVI

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 >

5 years, 1 month

1
0
0 0

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

by Janos Follath

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.

5 years, 1 month

1
0
0 0

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

by Hanno Becker

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

5 years, 1 month

1
0
0 0

Random Number Generator module in mbed TLS

by ROSHINI DEVI

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

5 years, 1 month

1
1
0 0

Edwards curve support (#3245): fixing mbedtls_ecp_get_type

by Aurelien Jarno

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

5 years, 1 month

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, 1 month

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, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls