Hello,
I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question?
Thanks and kind regards,
Shudong
Hi,
I have an ACME client library for esp32, and I try to extend it to
support multiple host names. First step is to include alternate names in
the CSR.
After I tried the ARMmbed issues forum, I was pointed to this list.
My code is in
http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/…
<http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/…>
(see function Acme::CreateAltUrlList) , the function below is an attempt
to do what I described, but doesn't work.
Can anyone help ?
Danny
int Acme::CreateAltUrlList(mbedtls_x509write_csr req) {
int l = 20;
int ret;
for (int i=0; alt_urls[i]; i++) {
l += strlen(alt_urls[i]) + 20;
}
unsigned char *buf = (unsigned char *)malloc(l), *p = buf + l;
int len = 0;
for (int i=0; alt_urls[i]; i++) {
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_raw_buffer(&p, buf, (const
unsigned char *)alt_urls[i], strlen(alt_urls[i])));
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf,
strlen(alt_urls[i])));
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf,
MBEDTLS_ASN1_CONTEXT_SPECIFIC | 2));
}
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf, len));
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf,
MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE));
if ((ret = mbedtls_x509write_csr_set_extension(&req,
MBEDTLS_OID_SUBJECT_ALT_NAME,
MBEDTLS_OID_SIZE(MBEDTLS_OID_SUBJECT_ALT_NAME),
(const unsigned char *)p, len)) != 0) {
char errbuf[80];
mbedtls_strerror(ret, errbuf, sizeof(errbuf));
ESP_LOGE(acme_tag, "%s: mbedtls_x509write_csr_set_extension failed %s
(0x%04x)", *__FUNCTION__*, errbuf, -ret);
}
free(buf);
ESP_LOGD(acme_tag, "%s: ret %d", *__FUNCTION*__, ret);
return ret;
}
--
Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info
Hi David,
Archive can be found here
https://lists.trustedfirmware.org/pipermail/mbed-tls/https://lists.trustedfirmware.org/pipermail/psa-crypto/
Regards,
Shebu
-----Original Message-----
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of David Higton via mbed-tls
Sent: Friday, June 25, 2021 2:51 PM
To: mbed-tls(a)lists.trustedfirmware.org
Subject: [mbed-tls] List archive?
Hi everybody,
I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it?
The information may have been staring me in the face; if that's the case, I apologise.
David
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi everybody,
I've just joined the list. The first thing I did was to try to find an
archive of list postings, but I haven't found one. Is there one, and,
if so, where do I find it?
The information may have been staring me in the face; if that's the
case, I apologise.
David
Hi Anasasija,
Mbed TLS is entirely agnostic of the communication channel or protocol. You can configure it to use any underlying layer, like TCP, UDP or even just a local buffer.
That said, we have a module that makes it more convenient to use Mbed TLS with TCP (or UDP) on common platforms:
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/net_soc…
You can see an example for using the module in several sample applications, for example:
https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… and
https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server…
Kind regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of 1637062--- via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Friday, 25 June 2021 at 09:27
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Is TCP integrated in mbed-TLS?
Hello,
I am a Student and for my bachelor thesis I am working on a tool that
is able to detect whether a server is vulnerable regarding
Bleichenbacher's attack or not, testing multiple side channels.
For this I am looking for a TLS implementation that has the TCP
protocol integrated and generates the TCP messages.
I was wondering if mbed-tls has the TCP integrated in the
implementation or not.
If so, I could make use of this information, too.
Thanks and kind regards,
Anastasija
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi Lijin,
It still can be the endianness of the keys. If the key is reversed, there won’t be any discernible pattern or relationship between the derived secrets.
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of T V LIJIN (EXT) via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Friday, 25 June 2021 at 09:15
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12
Hello,
We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness.
Could you please confirm that the code used for ECDHE key exchange is proper?
SHARED_SECRET (Computed on Client):
11 36 F7 DB 2B 14 BB 86
1C A0 FC DF 6D 4D 17 70
BE 4F D8 58 C2 11 67 10
42 D7 47 EB 14 4B 10 5E
SHARED_SECRET(Computed on Sever):
c6 96 d9 f0 ec 37 be 9e
1a 60 a4 5f 88 f2 13 d3
bb 98 15 3f 3b d9 81 37
c6 10 12 85 e5 8b 49 16
Thanks,
LIJIN T V
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org>
Sent: Friday, June 25, 2021 4:52 AM
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: mbed-tls Digest, Vol 16, Issue 12
This message is from an external sender. Be cautious, especially with links and attachments.
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT))
2. Re: ECDHE Shared Secret is computed differently (Brian D.)
3. How does the bignum.c works? (Shariful Alam)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jun 2021 13:35:03 +0000
From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com>
To: "mbed-tls(a)lists.trustedfirmware.org"
<mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] ECDHE Shared Secret is computed differently
Message-ID:
<AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello ,
We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
We have tested the same source code on Visual studio and found working.
I have attached the source files
Could you please comment on why the computed shared secret are different on both the ends?
Thanks,
LIJIN T V
Hello,
I am a Student and for my bachelor thesis I am working on a tool that
is able to detect whether a server is vulnerable regarding
Bleichenbacher's attack or not, testing multiple side channels.
For this I am looking for a TLS implementation that has the TCP
protocol integrated and generates the TCP messages.
I was wondering if mbed-tls has the TCP integrated in the
implementation or not.
If so, I could make use of this information, too.
Thanks and kind regards,
Anastasija
Hello,
We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness.
Could you please confirm that the code used for ECDHE key exchange is proper?
SHARED_SECRET (Computed on Client):
11 36 F7 DB 2B 14 BB 86
1C A0 FC DF 6D 4D 17 70
BE 4F D8 58 C2 11 67 10
42 D7 47 EB 14 4B 10 5E
SHARED_SECRET(Computed on Sever):
c6 96 d9 f0 ec 37 be 9e
1a 60 a4 5f 88 f2 13 d3
bb 98 15 3f 3b d9 81 37
c6 10 12 85 e5 8b 49 16
Thanks,
LIJIN T V
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org>
Sent: Friday, June 25, 2021 4:52 AM
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: mbed-tls Digest, Vol 16, Issue 12
This message is from an external sender. Be cautious, especially with links and attachments.
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
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. ECDHE Shared Secret is computed differently (T V LIJIN (EXT))
2. Re: ECDHE Shared Secret is computed differently (Brian D.)
3. How does the bignum.c works? (Shariful Alam)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jun 2021 13:35:03 +0000
From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com>
To: "mbed-tls(a)lists.trustedfirmware.org"
<mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] ECDHE Shared Secret is computed differently
Message-ID:
<AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello ,
We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
We have tested the same source code on Visual studio and found working.
I have attached the source files
Could you please comment on why the computed shared secret are different on both the ends?
Thanks,
LIJIN T V
Hello,
Can someone please briefly explain how does the bignum.c library works in
terms of RSA? I understand that this is too broad a question to ask. but If
someone can briefly explain the basic working mechanism it will be a great
help.
Thanks,
Shariful
Hi Linjin,
I am not part of the mbed-tls staff but I developed a lot with mbed library and I had your same problem. Try to check the byte order, I had issues when computing the shared secret because I had the little endian from the other side but mbed uses big endian.
Try to do a quick test and this could resolve your problem, let me know!
Bye,
Brian
24 giu 2021, 15:35 da mbed-tls(a)lists.trustedfirmware.org:
> Hello ,
> We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
> Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
> We have tested the same source code on Visual studio and found working.
> I have attached the source files
>
> Could you please comment on why the computed shared secret are different on both the ends?
>
> Thanks,
> LIJIN T V
>
