Hi,
I want to sign a data on PC with openssl, and verifiy it with PSA-RoT
on board. Does anybody know how to map PSA method to openssl method?
Such as:
psa_sign_hash(key_handle,
PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256), hash, hash_len, sig,
sizeof(sig), sig_len);
Regards,
Jun
Hi Gopi,
FN_NV_SEED_WR supposed to be called the first time the entropy context is used to retrieve some entropy. This is tracked by the `initial_entropy_run` member in the `mbedtls_entropy_context` structure (on the initial run it is zero, non-zero otherwise).
FN_NV_SEED_WR not being called might mean that your “Entropy” variable hasn’t been properly initialised or that it has been used before the callbacks are set.
Please note that Mbed TLS 2.16.2 has known bugs and vulnerabilities. You should upgrade to the latest bug-fixing version of the 2.16 branch, 2.16.10.
Best regards,
Janos
(Mbed TLS developer)
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Friday, 4 June 2021 at 05:50
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Cc: T V LIJIN (EXT) <lijin.tv(a)kone.com>
Subject: Re: [mbed-tls] NV_SEED read working and write not working
Hi,
I am working on a embedded platform, that does not has any entropy source except system ticks. To improve the randomness, I am trying to utilize NV_SEED operations. The version of mbedtls version 2.16.2 is being used.
Configuration file I have enabled:
#define MBEDTLS_ENTROPY_NV_SEED
#define MBEDTLS_PLATFORM_NV_SEED_ALT
After initializing and before seeding random number generator, I assign functions of nv seed read and write to platform seeding function as below.
if( r = mbedtls_platform_set_nv_seed(FN_NV_SEED_RD, FN_NV_SEED_WR) )
{
return( r );
}
if( r = mbedtls_ctr_drbg_seed( &CtrDrbg, mbedtls_entropy_func, &Entropy,
(const unsigned char *) u8SeedingString, (size_t)Length ) )
{
return ( r );
}
Later functions to generate random and free context.
While running, I could see only the FN_NV_SEED_RD function is getting called. And, FN_NV_SEED_WR function is not getting called. I tried to add some print statements in mbedtls library function, mbedtls_entropy_update_nv_seed().
But it looks like, this function was never called by the library.
1. Anything else to be done?
2. someone could help me ensure NV_SEED is properly incorporated
3. How to trace the issue.
Thanks,
Gopi Krishnan
Hi,
I am working on a embedded platform, that does not has any entropy source except system ticks. To improve the randomness, I am trying to utilize NV_SEED operations.
Configuration file I have enabled:
#define MBEDTLS_ENTROPY_NV_SEED
#define MBEDTLS_PLATFORM_NV_SEED_ALT
After initializing and before seeding random number generator, I assign functions of nv seed read and write to platform seeding function as below.
if( r = mbedtls_platform_set_nv_seed(FN_NV_SEED_RD, FN_NV_SEED_WR) )
{
return( r );
}
if( r = mbedtls_ctr_drbg_seed( &CtrDrbg, mbedtls_entropy_func, &Entropy,
(const unsigned char *) u8SeedingString, (size_t)Length ) )
{
return ( r );
}
Later functions to generate random and free context.
While running, I could see only the FN_NV_SEED_RD function is getting called. And, FN_NV_SEED_WR function is not getting called.
Could anyone suggest how to trace the issue. I do not have debugger on for my platform. I could debug only with print statements.
Thanks,
Gopi Krishnan
Hi all,
I'm using mbedTLS libraries with an OPTIGA cryptochip. At the moment,
when I call the sign function:
err = mbedtls_pk_sign(&priv_key, MBEDTLS_MD_SHA384, hash, 0, sign, &olen,
mbedtls_ctr_drbg_random, &ctr_drbg);
I need to pass it a valid private key else if it isn't used, because
alternative sign routine use the one into cryptochip.
It is possible to avoid passing this key?
Best regards,
Stefano Mologni
Hello,
We have requirements of parsing PKCS12 file in our project to import the
certificate. I have seen the code and am not able to find the related API
which can be used to parse the PKCS12 file. Do you have some sample example
code which does this work?
Thanks for your help.
--
Regards,
Sunil Jain
Hello,
We are porting MbedTLS 2.16 for FTP server. There are 2 connection in FTP
communication, Control and data.
For control communication we are ok with handshake but data communication
handshake is having issue. We have observed with FTP Client (FileZilla) our
earlier implementation of FTP server with Mocana secure library, we used to
send certificate and server key exchange in control communication handshake
only, for Data communication handshake ServerHello and change cipher spec
was sent. But in case of MbedTLS, we are sending certificate and server key
exchange in data communication handshake also. FTP Client (FileZilla) is
rejecting the handshake after receiving the server certificate server key
exchange and from the FTP server as I believe it is expecting session
resumption and FTP Server is waiting for client key exchange in handshake.
In attached wireshark trace, packet number 1570 is having issue.
When we tested this server with another FTP client (WinSCP), its working
fine as this client is not expecting session resumption.
As I go through the code documentation of MbedTLS, I found that we cannot
set the session resumption at server side, only client side we can do this
setting. How can we make FTP server ready with session resumption? Please
support us.
Thanks and Regards,
Sunil
Hi Gilles,
Thanks for the quick reply.
I migrated to version 2.16, and I have seen the same issue is still there.
Moreover, we have reseeded the RNG, still issue is there.
I created a client and it's working fine, it's able to handshake and send
data to the server. Only problem is server communication where control is
going in infinite loop while creating server key exchange. As you asked for
the call stack of the loop, I am attaching the call stack with this mail.
Please support us.
Thank you.
Regards,
Selin.
On Fri, May 21, 2021 at 5:30 PM <mbed-tls-request(a)lists.trustedfirmware.org>
wrote:
> Send mbed-tls mailing list submissions to
> mbed-tls(a)lists.trustedfirmware.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
> or, via email, send a message with subject or body 'help' to
> mbed-tls-request(a)lists.trustedfirmware.org
>
> You can reach the person managing the list at
> mbed-tls-owner(a)lists.trustedfirmware.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mbed-tls digest..."
>
>
> Today's Topics:
>
> 1. Re: Request for Support [Issue : Webserver handshake failing
> with self-signed certificate] (Gilles Peskine)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 May 2021 15:13:54 +0200
> From: Gilles Peskine <gilles.peskine(a)arm.com>
> To: mbed-tls(a)lists.trustedfirmware.org
> Subject: Re: [mbed-tls] Request for Support [Issue : Webserver
> handshake failing with self-signed certificate]
> Message-ID: <93c3cd71-bdc1-c3ec-4bbc-89ff995a8444(a)arm.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Selin,
>
> A possible problem could be a misconfigured random generator. However
> this is purely speculation. Can you get a stack trace? Finding the root
> cause requires finding where mbedtls_mpi_cmp_mpi is called.
>
> Please note that Mbed TLS 2.16.3 has known bugs and vulnerabilities. You
> should upgrade to the latest bug-fixing version of the 2.16 branch,
> 2.16.10.
>
> --
> Gilles Peskine
> Mbed TLS developer
>
> On 20/05/2021 13:06, Selin Chris via mbed-tls wrote:
> >
> > Hi,
> >
> > Thank you for adding me to the mbed-tls mailing list.
> >
> > We have created a self-signed certificate with ECC key of
> > MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate
> > after we send the certificate to chrome from our web server it shows
> > not trusted and goes to the page where we need to manually proceed
> > with the acceptance of the certificate to allow further communication.
> > After this we again have to perform handshake for which we need to
> > prepare the server key exchange, while preparing the server key
> > exchange we notice that it is infinitely calling the
> > mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not
> > able to proceed hereafter. Sometimes we also see that when executing
> > ssl_prepare_server_key_exchange() function in ssl_srv.c we find
> > ciphersuite_info pointer as null and the program goes into data panic
> > due to that. We have checked our stacks and not seen any sign of
> > corruption.
> >
> > The mbedtls version that we are using is mbedtls-2.16.3.
> > Please find the attached wireshark trace during this scenario. The IP
> > 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc
> > with the browser.
> >
> > Please let us know the root-cause of the issue and the actions to be
> > taken to fix this - can you please expedite as this is a blocking
> > issue in our project.
> >
> > Thanks for the support.
> >
> > Regards,
> > Selin.
> >
> >
> >
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
>
> ------------------------------
>
> End of mbed-tls Digest, Vol 15, Issue 8
> ***************************************
>
Hi
I am writing a server client with Libuv as tcp stack and mbedtls as ssl.
I am able to do a successful handshake between server and client but after
that when I try to write/read application data it fails with “Verification
of the message MAC failed”. After inspecting debug logs, I found the server
and client have the same Pre-master master secret and IV and still it is
failing. Currently both client and server are on the same machine . I am
attaching server and client logs. Any help is appreciated.
server.log
<https://drive.google.com/file/d/1oaMMV2_YVDL8GLn6GH3PIQSIH5BDbGeU/view?usp=…>
client.log
<https://drive.google.com/file/d/1Z9P1ssglqRpBUmXF9TuRQd6KJKvyw6RJ/view?usp=…>
Thanks
Vaibhav
Hi Selin,
A possible problem could be a misconfigured random generator. However
this is purely speculation. Can you get a stack trace? Finding the root
cause requires finding where mbedtls_mpi_cmp_mpi is called.
Please note that Mbed TLS 2.16.3 has known bugs and vulnerabilities. You
should upgrade to the latest bug-fixing version of the 2.16 branch, 2.16.10.
--
Gilles Peskine
Mbed TLS developer
On 20/05/2021 13:06, Selin Chris via mbed-tls wrote:
>
> Hi,
>
> Thank you for adding me to the mbed-tls mailing list.
>
> We have created a self-signed certificate with ECC key of
> MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate
> after we send the certificate to chrome from our web server it shows
> not trusted and goes to the page where we need to manually proceed
> with the acceptance of the certificate to allow further communication.
> After this we again have to perform handshake for which we need to
> prepare the server key exchange, while preparing the server key
> exchange we notice that it is infinitely calling the
> mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is not
> able to proceed hereafter. Sometimes we also see that when executing
> ssl_prepare_server_key_exchange() function in ssl_srv.c we find
> ciphersuite_info pointer as null and the program goes into data panic
> due to that. We have checked our stacks and not seen any sign of
> corruption.
>
> The mbedtls version that we are using is mbedtls-2.16.3.
> Please find the attached wireshark trace during this scenario. The IP
> 192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc
> with the browser.
>
> Please let us know the root-cause of the issue and the actions to be
> taken to fix this - can you please expedite as this is a blocking
> issue in our project.
>
> Thanks for the support.
>
> Regards,
> Selin.
>
>
>
Hi,
Thank you for adding me to the mbed-tls mailing list.
We have created a self-signed certificate with ECC key of
MBEDTLS_ECP_DP_SECP256R1 type, since it is a self-signed certificate after
we send the certificate to chrome from our web server it shows not trusted
and goes to the page where we need to manually proceed with the acceptance
of the certificate to allow further communication. After this we again have
to perform handshake for which we need to prepare the server key exchange,
while preparing the server key exchange we notice that it is infinitely
calling the mbedtls_mpi_cmp_mpi() function in bignum.c and the execution is
not able to proceed hereafter. Sometimes we also see that when executing
ssl_prepare_server_key_exchange() function in ssl_srv.c we find
ciphersuite_info pointer as null and the program goes into data panic due
to that. We have checked our stacks and not seen any sign of corruption.
The mbedtls version that we are using is mbedtls-2.16.3.
Please find the attached wireshark trace during this scenario. The IP
192.168.2.67 corresponds to our webserver and 192.168.2.100 the pc with the
browser.
Please let us know the root-cause of the issue and the actions to be taken
to fix this - can you please expedite as this is a blocking issue in our
project.
Thanks for the support.
Regards,
Selin.
Hi Manoj,
As you might have seen, TLS1.3 prototype is available in github
https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype
The project is working on reviewing the prototype and upstreaming parts of it to Mbed TLS.
The currently open pull requests to Mbed TLS project can be found here: https://github.com/ARMmbed/mbedtls/labels/MPS%20%2F%20TLS%201.3
Some of the outstanding work is captured here - https://github.com/ARMmbed/mbedtls/projects/2#column-12964476
If possible, please test the TLS1.3 prototype and let know if you have any feedback. Also welcome to review any patches.
1. Expected date for release of MbedTLS with TLS 1.3 support?
A subset of TLS 1.3 features is aimed to be available around the last quarter of 2021. TLS1.3 support in Mbed TLS at that point would be limited for TLS (no DTLS), Client side and ECDHE.
There won't be support for server side, PSK and 0-RTT in this initial version. Note the last quarter target is based on high level task estimations and can change based on progress made in the coming months.
You can use the prototype above in the interim for prototyping/development purposes. It is not expected to be integrated on production platforms though.
1. Is MbedTLS with TLS 1.3 support available under paid subscription?
No, there is no paid offerings in Mbed TLS project.
Mbed TLS project is an open source community project under trustedfirmware.org (https://www.trustedfirmware.org/) and is available to use under the open source license (Refer license section - https://github.com/ARMmbed/mbedtls).
1. Process for paid subscription (if point #2 applicable)
Not Applicable
Regards,
Shebu
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org<mailto:mbed-tls-bounces@lists.trustedfirmware.org>> On Behalf Of Manoj Srivastava via mbed-tls
Sent: Monday, May 17, 2021 8:57 PM
To: mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] Query for TLS 1.3
Hello,
I am using mbedTLS for TLS support. I am looking for TLS 1.3 support for PSK only mode. I have checked source code online but didn't get TLS 1.3 PSK only code. I found all prototype code only. Can you please highlight the repository if the same is available ?
In case fixed code for TLS 1.3 for PSK only mode is not available then can please answer followings:
1. Expected date for release of MbedTLS with TLS 1.3 support?
2. Is MbedTLS with TLS 1.3 support available under paid subscription?
3. Process for paid subscription (if point #2 applicable)
Best Regards,
Manoj Srivastava
Hello,
I am using mbedTLS for TLS support. I am looking for TLS 1.3 support for PSK only mode. I have checked source code online but didn't get TLS 1.3 PSK only code. I found all prototype code only. Can you please highlight the repository if the same is available ?
In case fixed code for TLS 1.3 for PSK only mode is not available then can please answer followings:
1. Expected date for release of MbedTLS with TLS 1.3 support?
2. Is MbedTLS with TLS 1.3 support available under paid subscription?
3. Process for paid subscription (if point #2 applicable)
Best Regards,
Manoj Srivastava
Hi,
thanks a lot for the fast reply and sorry for my late answer but I did a lot of tests in order to solve the problem (I never had success on compute shared function when "talking" with another peer).
Yes, you're right, no need to modify anything. The issue was that mbedtls uses ecp point coordinates in big endian format while the other peer bytes were intended to be in little endian format.
After reversing the bytes before compute shared everything worked!
Thank you, have a nice day!
Brian
3 mag 2021, 21:53 da mbed-tls(a)lists.trustedfirmware.org:
> Hi Brian,
>
> It's not clear to me what you're trying to do. Mbed TLS supports
> Curve25519 arithmetic for X25519, accessible through the
> mbedtls_ecdh_xxx interface. If you want to use Curve25519 for some other
> purpose, this may or may not be supported via direct access to the
> mbedtls_ecp_xxx interface. The curve arithmetic code only supports
> predefined groups, it does not support changing the generator without
> patching the library.
>
> For Curve25519, the generator is the point (X,Z)=(9,1). Isn't this the
> generator you want?
>
> Best regards,
>
> --
> Gilles Peskine
> Mbed TLS developer
>
> On 30/04/2021 17:39, Brian via mbed-tls wrote:
>
>> Hi all,
>> I'm trying to set the generator g to a value of 9 for the Curve25519 with mbedtls_ecp_gen_key function. However I cannot find any way to accomplish that.
>> Could anyone help me?
>> Thank you, have a nice day,Brian
>>
>
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
Hi,
I'm trying to integrate NXPs secure element SE050 into an application running on MSP432E401Y chip.
I was able to successfully integrate their middleware(Plug and trust) on a baremetal project with mbedTLS enabled.
It seems on this baremetal project, entropy_source (from entropy_alt.c) is not working. And this has a knock on effect on mbedtls_ctr_drbg_seed function which fails and takes the entire project down with it.
Also, from the sole example given in the Simplelink SDK (tcpechotls), I see that mbedtls is used in a project with RTOS enabled.
Should I try integrating this code in an RTOS based project and check? Has anyone worked on this ?
Thanks,
Devi Pandurangan
Lead Engineer - Embedded Software
Armstrong Fluid Technology
#59, "Hampapura Mane"
3rd Main, Margosa Road, Malleswaram, Bangalore, Karnataka, 560 003, India
T : +91-80-49063555<tel:+91-80-49063555> | F : +91-80-23343535
www.armstrongfluidtechnology.com
[cid:image001.jpg@01D741AF.326E2340]<http://www.armstrongfluidtechnology.com/>
[cid:image002.jpg@01D741AF.326E2340]<http://twitter.com/ArmstrongFT_UK>
[cid:image003.jpg@01D741AF.326E2340]<http://plus.google.com/+Armstrongfluidtechnology>
[cid:image004.jpg@01D741AF.326E2340]<http://www.linkedin.com/company/armstrong-fluid-technology>
[cid:image005.jpg@01D741AF.326E2340]<http://www.youtube.com/user/ArmstrongFT>
[cid:image006.jpg@01D741AF.326E2340]<https://www.facebook.com/ArmstrongFluidTechnology/>
[cid:image007.jpg@01D741AF.326E2340]<https://www.flickr.com/photos/armstrongintegrated/collections/>
DISCLAIMER: This email and any attachments are sent in confidence, subject to applicable legal
privilege and upon the basis that the recipient will conduct appropriate checks. If you have received
this email in error, please send it back to us and immediately and permanently delete it: you are strictly
prohibited from using, copying or disclosing it or any information contained in it or in any attachment.
Internet communications are not secure and Armstrong Design Private Limited is not responsible for
their abuse by third parties, nor for any alteration or corruption in transmission, nor for any damage or
loss caused by any virus or other defect. Armstrong Fluid Technology is a trading name of Armstrong
Design Private Limited, #59, First Floor, 3rd Main Margosa Road, Malleswaram, Bangalore, 560 003,
India registered in India company no. 029120KA2004PTC034014.
Hello Younes,
I assume that you recently joined the list here.
In that case: Please welcome!
Since ole times of Usenet it is a common behaviour to first subscribe a
list/channel and listen to the posts.
After some time write your own first email to the list, introduce
yourself quickly and write about your problem.
But please do never start with an email carrying "URGENT" in subject.
This is not politely.
See, the people maintaining this list do this without any fees. The
spent their time to answer questions "from the community" for free.
And they do it well! Hence please avoid galopping in here. ;-)
You want https and sftp implementations, which are layer 7 and actually
mostly on a different/higher layer then mbed TLS.
And they are not trivial - there is NO SIMPLE implementation!
Please compare it to projects like e.g. Apache or OpenSSH: The people
required months/years to get an implementation.
Regarding the C code you sent: Obviously it is at least partly coming
from STM and it has a size of more than 50 KiB.
Why did you sent that? This is not just a code snippet of a few lines.
Did you actually expect that anyone would analyze it?
Maybe someone is on this list who knows the code and can give you some
hints. But don't expect a "working example of https and sftp".
Hence my personal answer:
- Basic examples like "client" and "server" are already provided by mbed
TLS! You just need to extend them with https and sftp protocol.
- If you want to use a SIMPLE implementation then please use Python or
Java/Groovy. Because then you don't need to know most of the technical
details of https and sftp.
- If you are looking for many "working examples" of code then you should
also think about using a lib like OpenSSL which is mostly used.
And please be politely. Please remember that the people here are giving
support for free. Great support for free.
cheers,
Frank
On 03.05.21 21:11, Younes Boulahya via mbed-tls wrote:
> I am using STM32F303RCT6 and W5500, I want to upgrade to HTTPS and
> SFTP, but I can't find any working example that I can use, can you
> provide me a simple one PLEASE, of both HTTPS and SFTP.
>
> I attach my current c code, thank you so much 🌷
>
--
Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753
SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606
http://tdyn.de/freel -- Redirect to profile at freelancermap
http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP
Hi Brian,
It's not clear to me what you're trying to do. Mbed TLS supports
Curve25519 arithmetic for X25519, accessible through the
mbedtls_ecdh_xxx interface. If you want to use Curve25519 for some other
purpose, this may or may not be supported via direct access to the
mbedtls_ecp_xxx interface. The curve arithmetic code only supports
predefined groups, it does not support changing the generator without
patching the library.
For Curve25519, the generator is the point (X,Z)=(9,1). Isn't this the
generator you want?
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 30/04/2021 17:39, Brian via mbed-tls wrote:
> Hi all,
> I'm trying to set the generator g to a value of 9 for the Curve25519 with mbedtls_ecp_gen_key function. However I cannot find any way to accomplish that.
> Could anyone help me?
> Thank you, have a nice day,Brian
<mbed-tls(a)lists.trustedfirmware.org>I am using STM32F303RCT6 and W5500, I
want to upgrade to HTTPS and SFTP, but I can't find any working example
that I can use, can you provide me a simple one PLEASE, of both HTTPS and
SFTP.
I attach my current c code, thank you so much 🌷
Hi all,
I'm trying to set the generator g to a value of 9 for the Curve25519 with mbedtls_ecp_gen_key function. However I cannot find any way to accomplish that.
Could anyone help me?
Thank you, have a nice day,Brian
Good morning,
I'm testing a routine that verify the validity of an intermediate
certificate, against my root certificate.
Both certificates are generated on my machine.
The code to do this is here: https://wtools.io/paste-code/b4OL
I can do the verify with openSSL and works fine.
When I pass certificates tombedTLS it returns these errors:
The certificate is signed with an unacceptable hash.
The certificate is signed with an unacceptable PK alg (eg RSA vs ECDSA).
The certificate is signed with an unacceptable key (eg bad curve, RSA too
short).
Can someone help me to find the mistakes?
Thanks for your help.
ROOT CERTIFICATE:
-----BEGIN CERTIFICATE-----
MIIB8TCCAXagAwIBAgIBATAMBggqhkjOPQQDAgUAMDkxCzAJBgNVBAMMAkNBMR0w
GwYDVQQKDBRDb21lbGl0IEdyb3VwIFMucC5BLjELMAkGA1UEBhMCSVQwHhcNMDEw
MTAxMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjA5MQswCQYDVQQDDAJDQTEdMBsGA1UE
CgwUQ29tZWxpdCBHcm91cCBTLnAuQS4xCzAJBgNVBAYTAklUMHYwEAYHKoZIzj0C
AQYFK4EEACIDYgAE/u9D/9E9S8kmJ5W75GwaZxUuXYuCYfszCsjNEuylVMj8N1r6
Ce+FJ3eSKQGgh2/H2Pd5Ck7TENQSuVBZIVsUcUv5q/MGGJWUNLCSZm2b5kadVKXQ
6Cn6t7RDFQ0IvRoLo1AwTjAMBgNVHRMEBTADAQH/MB8GA1UdIwQYMBaAFOzrPv2f
Rkotop0JzDEg/9CtjcRjMB0GA1UdDgQWBBTs6z79n0ZKLaKdCcwxIP/QrY3EYzAM
BggqhkjOPQQDAgUAA2cAMGQCMAxEjQOUP2hC3yhGIkz04Y9fFR6WWH8kUqQEutfb
57Q9ADRFsmAVtJgOZEsVhnZ6ugIwcRK7dngvNozV9Uu4ifhDCLF7qQhAH4XyQ/WI
GgKtCIBIps/H+JQNqjpwsVs8zlER
-----END CERTIFICATE-----
INTERMEDIATE CERTIFICATE:
-----BEGIN CERTIFICATE-----
MIIDDDCCAo+gAwIBAgIBATAMBggqhkjOPQQDAgUAMDkxCzAJBgNVBAMMAkNBMR0w
GwYDVQQKDBRDb21lbGl0IEdyb3VwIFMucC5BLjELMAkGA1UEBhMCSVQwHhcNMDEw
MTAxMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBozE+MDwGA1UEAww1Q29tZWxpdCBD
bG91ZCBBcyBEZXYgS2ZHWUFjWHg5U3NvMnlic3plcDRQTjZjR295R1BMaTAxJjAk
BgNVBAsMHUNvbWVsaXQgR3JvdXAgU3BhIC0gQ2xvdWQgTGFiMRowGAYDVQQKDBFD
b21lbGl0IEdyb3VwIFNwYTEQMA4GA1UECAwHQmVyZ2FtbzELMAkGA1UEBhMCSVQw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCfGrKbFRgC5o8REbcYdRzW
FXS772+CC15nXCJR67gWL1wmKzrCekkFNlOnQrsPhe4iYnkhLuBYNWaVvSaHt9dS
X/ZBbJ3bRnGAarw7QnirLZJFYSRRBhMw6xi91nt8kIvcA6kACFcooaRmg/jQzCyb
eXO1skJhDv13TxwDB8UTtRkfOTFl23FekMPWmJpqU1YxjAAYRtcY4jGAtV4D7T3V
3WjZ0eaIjl9n2g9/slG6p3ZSjONIRmyTiBRQNynKCxy1Q9Px1ohDCcS2SsK0smy6
0EzCghEz8QjAWs7U9Ilh3OTCdCpV9clp1DQrjbDZky1rMEd7mRmTp8Fmd2c3ld0F
AgMBAAGjUDBOMB0GA1UdDgQWBBT3OOc7ZPbeOBTkeYPBFQcQTLhECDAfBgNVHSME
GDAWgBTs6z79n0ZKLaKdCcwxIP/QrY3EYzAMBgNVHRMEBTADAQH/MAwGCCqGSM49
BAMCBQADaQAwZgIxAJvrL0kIeB4mvRJT1MRA0Kc/mw5ZVVv0ErOQqLhQShECw6+K
s5DL9V/tHf72iCCivAIxANfBJ2IMLzSZCOrSmr9fOCQktM6mFC5PyAuZX+3OGPfU
UuJwph7GaoWW+fw1IxQm2Q==
-----END CERTIFICATE-----
Thanks a lot,
Stefano
Hi,
Today we are switching our branches around, so that the development branch focuses on Mbed TLS 3.0, to be released mid-year. This will include API-breaking changes.
2.x development work will continue on the development_2.x branch. After merging development_3.0 onto development, the development_3.0 branch will be removed.
There is no change to the process for submitting PRs: new PRs should continue to target development, with backports to 2.x and 2.16 as needed. (The exception would be a bug-fix that only affects older branches, which would only need ports to the affected branches and not to development).
As part of the 3.0 work, we are looking at various things that can be removed from the library. For some of these, we’ve notified the mailing list – please let us know in the next week if you have a good reason for retaining the feature in question.
- Remove support for TLS 1.0, TLS 1.1 and DTLS 1.0 https://github.com/ARMmbed/mbedtls/issues/4286
- Remove support for the "Truncated HMAC" (D)TLS extension https://github.com/ARMmbed/mbedtls/issues/4341
- Remove support for 3DES ciphersuites in (D)TLS https://github.com/ARMmbed/mbedtls/issues/4367
- Remove support for RC4, Blowfish, XTEA, MD2 and MD4 https://github.com/ARMmbed/mbedtls/issues/4084
- Remove support for pre-v3 X.509 certificates with extensions https://github.com/ARMmbed/mbedtls/issues/4386
- Remove the RSA key mutex https://github.com/ARMmbed/mbedtls/issues/4124
- Remove MBEDTLS_CHECK_PARAMS https://github.com/ARMmbed/mbedtls/issues/4313
- 3.0 and 2.x :- Minimum development environment: is it OK to require Python >= 3.6 and/or CMake >= 3.5.2? https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-March/000319.html
Dave Rodgman
Hello,
A number of files in the Mbed TLS source tree are automatically
generated from other files, with a content that does not depend on the
platform or configuration. We are considering removing the generated
files from the development branch in Git, at least during the work
towards Mbed TLS 3.0. This would affect at least the development branch
until the 3.0 release, and may affect the development_2.x branch and the
development branch after the 3.0 release. Long-time support branches and
official releases will continue to have these source files in the Git tree.
The reason to remove the generated files is to facilitate development,
especially with the restructuring that is happening as we prepare a new
major version of the library. This is an experimental change; depending
on how effective it is, we may or may not wish to restore the generated
files on the development branch when 3.0 stabilizes. It's also still
possible that we will not go ahead with this change, depending on the
impact on our CI and on the feedback we receive.
The affected files are:
* Two library source files: library/error.c and library/version_features.c.
* Parts of some test programs: programs/test/query_config.c and
programs/psa/psa_constant_names_generated.c.
* The Visual Studio project files.
* Some unit test data files.
What does this change for you?
**If you were using a long-time support branch or an official release**:
no change.
**If you were using the supplied GNU Makefile**: there should be no
effective change.
**If you were using CMake, Visual Studio or custom build scripts** on
the development branch: Perl (>=5.8) will be required to generate some
library sources and to generate the Visual Studio project files. Python
(>=3.4) was already required to run config.py and to build the unit
tests. Note that the generated files are independent of the Mbed TLS
configuration, so if your deployment has a pre-configuration step, you
can generate the files at this step: no new tool is required after the
library is configured.
The ongoing work (not complete yet as I write) is at
https://github.com/ARMmbed/mbedtls/pull/4395 if you want to see what
this change means concretely.
We are aware that the additional dependencies are a burden in some
environments, which is why we will definitely not change anything to
releases or to current and future long-time support branches. If you are
building Mbed TLS from the development branch and this change affects
you, please let us know what constraints apply to your environment.
Best regards,
--
Gilles Peskine
Mbed TLS developer
Hello,
The macro MBEDTLS_MPI_CHK sets ret, so this particular case is safe.
That being said, we do have a hygiene rule to initialize ret variables,
to avoid accidentally having uninitialized variables in edge cases. I'll
file an issue to fix those.
Thanks for reaching out!
--
Gilles Peskine
Mbed TLS developer
On 21/04/2021 17:33, momo 19 via mbed-tls wrote:
> Hello,
>
> I would like to report a possible bug in rsa_prepare_blinding function
> in rsa.c
> (https://github.com/ARMmbed/mbedtls/blob/v2.26.0/library/rsa.c
> <https://github.com/ARMmbed/mbedtls/blob/v2.26.0/library/rsa.c>). I am
> not sure if it is a real issue, but I think that there is a
> possibility to use uninitialized variable ret:
>
> static int rsa_prepare_blinding( mbedtls_rsa_context *ctx,
> int (*f_rng)(void *, unsigned char *, size_t), void
> *p_rng )
> {
> int ret, count = 0; <--- uninitialized variable ret
> mbedtls_mpi R;
>
> mbedtls_mpi_init( &R );
>
> if( ctx->Vf.p != NULL )
> {
> /* We already have blinding values, just update them by
> squaring */
> MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vi, &ctx->Vi,
> &ctx->Vi ) );
> MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vi, &ctx->Vi,
> &ctx->N ) );
> MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vf, &ctx->Vf,
> &ctx->Vf ) );
> MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vf, &ctx->Vf,
> &ctx->N ) );
>
> goto cleanup; <--- going to cleanup without setting a value of ret
> }
>
> (Skipping lines for readability)
>
> cleanup:
> mbedtls_mpi_free( &R );
>
> return( ret ); <--- returning uninitialized variable ret
> }
>
> Best regards,
> grapix121
>
>