- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Support for ECDH key generation with Curve25519

by brian_d＠tutanota.com

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 >

3 years, 4 months

1
0
0 0

Not sure if the TLS implementation is correct or not

by Younes Boulahya

Please see these 2 stackoverflow posts: Implementing TLS over HTTP in STM32F303RC using W5500 <https://stackoverflow.com/questions/67522903/implementing-tls-over-http-in-…> HTTPS Handshake Debugging <https://stackoverflow.com/questions/67534996/https-handshake-debugging> In short I have implemented mbedtls over an HTTP Client but I am not sure if it's working or not, when I debug using wireshark I can see the handshake and the encrypted data sent to the server, but I don't see any records added to mysql database. [image: 1.PNG]

3 years, 4 months

1
0
0 0

mbedTLS -entropy source issue

by Pandurangan, Devi

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.

3 years, 4 months

1
0
0 0

Re: [mbed-tls] URGENT PLEASE

by Frank Bergmann

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

3 years, 5 months

1
0
0 0

Re: [mbed-tls] Support for ECDH key generation with Curve25519

by Gilles Peskine

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

3 years, 5 months

1
0
0 0

URGENT PLEASE

by Younes Boulahya

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

3 years, 5 months

1
0
0 0

Support for ECDH key generation with Curve25519

by brian_d＠tutanota.com

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

3 years, 5 months

1
0
0 0

Problems during certificate verifing

by stefano664

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

3 years, 5 months

1
0
0 0

Mbed TLS 3.0 branch transition

by Dave Rodgman

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

3 years, 5 months

1
0
0 0

Removal of generated source and build files from the development branch

by Gilles Peskine

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

3 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls