The |mbedtls| client project I'm working on, is to also support the
cipher suites: |TLS-ECDHE-ECDSA-WITH-AES-256-CCM| &
|TLS-ECDHE-ECDSA-WITH-AES-128-CCM|. I have specified them like:
|const int ciphersuites[] = {
MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384,
MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_256_CCM, 0 };
mbedtls_ssl_conf_ciphersuites(&ctxt->conf,ciphersuites); |
and while I can see the GCM ciphers in the |Client Hello|, I cannot see
the |CCM| ciphers.
In |mbedtls/include/mbedtls/config.h|, the following are enabled:
|#define MBEDTLS_CCM_ALT #define MBEDTLS_CCM_C #define
MBEDTLS_ECDH_GEN_PUBLIC_ALT #define MBEDTLS_ECDH_COMPUTE_SHARED_ALT
#define MBEDTLS_ECDSA_SIGN_ALT |
What is still missing?
While CCM is not listed under The following ciphers may be included
<https://tls.mbed.org/module-level-design-cipher>, the ciphers i would
like to add definitely show up under Supported SSL / TLS ciphersuites
<https://tls.mbed.org/supported-ssl-ciphersuites>,
Can someone help out?
Hello,
*RAM USAGE:*
We are using mbedTLS 2.16 for TLS communication and found that it is
consuming more RAM compared to other Cybersecurity library (Mocana ) which
we were using earlier. I want to reduce the RAM usage, if there are any
settings which i can apply to reduce the RAM usage
Presently MbedTLS is using almost 38KB of RAM per TLS connection, I have
small memory in my device (STM32F437), I want to reduce this RAM
consumption to 30KB per TLS connection.
*SLOWNESS:*
we have found that after 4 TLS connections on STM32F437 controller,
communication becomes very slow, we measured the CPU utilization at this
point of time, and it's only 40% ustilized, we are not getting any clue
why it becomes so slow. When we compare with Mocana cyber security library
we were able to run 6 TLS connections with good speed.
Please help us with the above 2 topics.
--
Thanks and Regards,
Sunil Jain
Hi mbedTLS team,
Our teams are in the process of reviewing available TLS library options. Is
there any information that we can find with respect to the mbedTLS stance
on TLS 1.3 support? I.E is there a timeline available supporting TLS 1.3?
Alternatively is there documentation available that outlines the expected
deltas between TLS 1.2 and 1.3 that can help compare the value gained by
using TLS 1.3 instead of 1.2?
Regards,
Alex Sukhov
Geotab
Embedded System Developer, Team Lead
Toll-free
Visit
+1 (877) 431-8221
www.geotab.com
Twitter <https://twitter.com/geotab> | Facebook
<https://www.facebook.com/Geotab> | YouTube
<https://www.youtube.com/user/MyGeotab> | LinkedIn
<https://www.linkedin.com/company/geotab/>
When we are using the version *mbedtls-2.16.6* with *libiec61850-1.5*, the
TLS connection is established successfully. But when we use the *2.7.19*,
the connection fails(we renamed *mbedtls 2.7.19* as *mbedtls 2.16* and put
in the folder third_party\mbedtls ).
We had occurred following error during the execution of client- server
example programs tls_server_example and tls_client_example using 2.7.19
version.
During handshaking process till CASE "
MBEDTLS_SSL_CLIENT_CHANGE_CIPHER_SPEC " it worked as expected.
But In CASE "MBEDTLS_SSL_CLIENT_FINISHED" the return value should be zero.
But we got in function mbedtls_ssl_safer_memcmp
mac_peer==41155316
mac_expect==41155356
diff=255 (this value has to be 0 for connection establishment)
But we are getting 255 constantly in all runnings.
Kindly help us to resolve the issue. If this issue is due to the non
supporting of mbedtls version ?.Thanks in advance.
Please let us know the *supporting versions of mbedtls *for
*libiec61850-1.5 *.
Hello,
Mbed TLS supports building and running unit tests in one of two modes:
“hosted” or “on target”. The on-target mode relies on Greentea, the Mbed
OS test framework. The on-target mode is unmaintained (there's no CI for
it and the Mbed TLS maintainers hardly ever even try to build it these
days) and we're considering retiring it in Mbed TLS 2.28.
If you do use Mbed TLS's on-target unit testing, either by building
target_test.function or by plugging your own file instead of
target_test.function or host_test.function, please let us know and weigh
in on https://github.com/ARMmbed/mbedtls/issues/4912
<https://github.com/ARMmbed/mbedtls/issues/4912> .
Best regards,
--
Gilles Peskine
Mbed TLS developer
Hello,
I'm using an older version of mbedtls (polarssl-1.3.9).
I have a plain text private key generated from OpenSSL like the following.
I'm trying to load this private key into the *rsa_context *using the
following code (sorry, for the following code, I just don't know what to
copy),
Private key with padding (I have added padding manualy to make it divisible
by 16 )
==================================================
// Total private key size is 4013
# define KEY_BUFFER_SIZE 4017
unsigned char private_decrypt[KEY_BUFFER_SIZE];
*printf("private key with padding --> \n %s \n", private_decrypt); -->
shows the following*
private key with padding -->
RSA Private-Key: (2048 bit, 2 primes)
modulus:
00:cc:40:c3:c6:e7:29:ae:f5:94:d8:3b:3f:a4:33:
c2:6d:29:86:63:db:b7:8c:d4:07:f7:b3:db:96:83:
f7:55:dd:6a:7b:04:49:53:3d:52:30:5f:af:0b:c2:
b1:f0:48:a4:66:0a:b7:aa:29:b1:d0:91:4f:9c:1c:
cf:df:5c:10:04:85:f9:bd:7b:93:ed:a6:77:80:12:
34:64:19:1a:18:b5:4e:94:7c:39:ce:99:38:50:e9:
82:71:f6:0f:3e:b8:af:11:3c:f4:05:69:72:8e:96:
f6:81:ac:46:29:eb:88:88:c5:54:2f:89:1b:b9:32:
da:76:23:a2:00:76:a5:8e:50:d3:ba:39:35:f9:4d:
95:63:ff:6a:3c:c8:a8:53:aa:78:d8:81:c8:bd:af:
cf:6c:de:33:aa:c9:d4:80:2c:1f:ef:92:90:8a:c4:
88:e6:9a:e5:ad:2d:08:60:89:1a:77:fc:bf:68:64:
6f:c0:a7:fa:33:6d:ff:d2:e6:a4:7f:ad:87:be:0c:
cb:9d:18:44:57:fe:db:86:7f:0b:c5:f7:9a:29:4b:
61:62:48:91:01:f7:e7:5e:64:4d:20:ec:ac:3c:07:
59:d6:19:f5:8c:01:9f:d5:6e:16:a8:8e:f9:2d:f6:
f8:73:25:0a:b5:d8:62:2a:f8:ba:d5:dc:ff:6e:77:
0d:35
publicExponent: 65537 (0x10001)
privateExponent:
4a:17:50:2d:2d:9b:5c:40:ef:3e:44:b7:c0:3b:9a:
52:78:d6:ac:10:7e:93:92:32:55:b3:23:7b:84:e1:
4a:7f:67:e9:b9:d3:53:63:92:15:c4:0f:be:47:60:
be:95:cb:34:cc:bc:74:f8:6c:ed:08:59:05:7b:1a:
18:9e:cf:9c:a4:70:c4:40:38:97:e3:63:c3:cc:56:
be:dc:b0:2f:b8:4d:09:e5:ca:1e:5c:4c:26:65:9e:
10:f2:bd:f2:f5:91:63:c2:65:8e:35:02:fe:20:5a:
c9:0d:11:e2:90:f2:d5:12:27:88:9a:c6:b8:b6:6e:
b2:9e:18:5c:ec:ac:ff:63:42:94:b3:b5:ff:69:75:
f5:e9:41:77:8b:ee:1d:fa:47:78:9a:9c:1f:84:8b:
85:f9:29:a5:27:e4:1f:04:34:4e:ce:c2:28:18:38:
72:63:5c:44:88:4f:e2:ec:bc:c4:3e:af:d8:bb:a9:
0f:c9:30:0f:bf:bc:1d:8a:fc:d9:cf:27:f5:16:38:
34:07:3d:bf:a5:45:70:df:c5:8f:ee:79:3e:69:6e:
e4:0c:74:76:f7:8a:2c:11:34:53:60:27:c3:73:55:
62:d5:06:cb:35:a4:3d:d6:79:3f:50:d4:81:7c:0f:
03:c5:15:b2:4a:eb:84:f1:16:07:ec:16:02:e4:5c:
1d
prime1:
00:e5:40:6a:4c:8d:d3:8d:8d:e6:df:e7:1d:c4:8f:
4d:b4:b7:71:51:b7:c4:8a:19:fe:fd:3e:4b:a9:0b:
d0:22:64:e0:76:f4:8b:88:d6:30:4b:f6:41:ae:20:
c5:cc:79:ec:05:d0:6b:0e:64:16:c5:b5:e3:74:b6:
a8:ac:39:74:1d:8a:09:b8:68:64:a4:c1:74:fa:f6:
cd:1b:24:d6:86:1e:40:51:dc:09:78:76:8b:16:3e:
f1:ea:a9:9b:25:69:4a:c4:3e:ba:63:62:6c:06:40:
83:8d:af:69:89:bd:ad:07:f4:97:39:7c:25:59:80:
07:59:4e:74:a0:4b:2a:05:67
prime2:
00:e4:15:a8:6a:e6:30:95:d6:36:44:a7:57:ac:99:
d5:4d:d9:58:59:05:49:89:b8:42:cb:0e:e8:9d:12:
fc:a4:76:e7:07:11:08:97:05:7d:0a:34:21:23:03:
c9:4b:97:5c:6f:fc:7e:28:8a:c5:b1:44:12:61:03:
60:5e:f9:d2:51:cf:53:0f:7a:2f:a5:96:5a:f5:33:
f7:6f:6e:92:14:cc:54:b1:48:ad:da:f7:37:c7:ca:
6f:a2:6a:00:de:73:6c:67:59:78:af:e9:ce:fb:02:
95:f8:0d:82:38:02:79:e5:a4:3b:61:16:b7:70:b1:
70:c8:9a:e8:81:c7:cb:fb:03
exponent1:
57:04:78:54:ce:90:ba:6e:5e:70:26:9d:d9:fa:3b:
18:99:78:dd:f7:cf:16:4c:7f:c9:48:58:17:b6:70:
2e:5d:f4:05:b3:15:33:bf:79:5d:9b:ff:9a:44:be:
4f:bb:07:a7:bd:50:a5:89:c0:4b:13:9b:5e:b5:e6:
98:58:c6:86:5f:db:08:b0:37:63:82:3b:10:f7:95:
2a:f4:74:a9:3b:da:56:38:1b:30:2a:6e:e8:e6:c3:
94:bb:04:34:d3:1e:9a:16:e5:50:cc:0f:0c:e0:78:
0e:d3:c2:4f:92:3b:97:85:73:d1:52:1a:2b:3a:b9:
8f:60:84:4c:43:bb:93:89
exponent2:
00:d7:ea:08:bc:e9:9c:24:bb:dc:33:b1:96:b5:b6:
0a:ce:df:69:5b:1c:3e:39:39:4d:41:9c:a3:67:ce:
89:8b:c7:63:7c:b5:0b:44:ab:d5:6a:cb:5e:73:1f:
2a:77:7c:99:ed:09:41:04:70:1a:25:6d:23:58:e3:
31:5f:b7:6e:fa:33:21:96:0d:3c:fd:ac:0f:fe:ff:
6a:c4:fa:0f:1f:d1:2e:7b:85:29:cf:97:28:1e:e1:
ec:3b:fb:cd:46:c8:4d:5e:a8:bc:2f:0b:4e:fd:1f:
bd:88:4c:81:71:34:26:e0:d5:4f:c0:e1:18:56:7e:
23:1e:44:46:c6:54:b5:2c:b1
coefficient:
2e:45:e5:0a:bc:66:bc:6e:9d:0d:ce:02:d6:30:62:
44:f6:38:d0:a7:2a:25:c4:42:76:cc:59:38:af:35:
cb:6e:a7:5e:3c:71:97:6a:7b:c4:69:25:2e:c4:07:
20:2c:86:5c:a1:e8:6e:d8:e6:b7:9a:21:28:1e:8a:
b1:4b:c5:ab:4e:35:e0:83:b5:30:56:53:d7:50:2f:
69:a2:6c:7b:00:d8:15:17:bb:79:72:33:30:11:47:
06:c5:58:16:63:e3:f5:ac:71:3d:ce:64:67:0e:6a:
e0:cd:c2:e6:ad:30:f9:3e:7e:52:01:cf:fc:fc:66:
10:44:1a:4b:1b:08:7a:8d
000 <----- padding
============================================
Remove padding and get the actual private key using the the following code,
=============================================================================
size_t lenght=strlen(private_decrypt); // length =4016
int N= lenght-4013; // 4013 is the original length of the private key, N
is the length of padding
private_decrypt[lenght-N]='\0'; // So, now *private_decrypt *contains the
actual key
=============================================================================
Then I use the following code to split each key and load into rsa_context,
=====================================================================
char *strings[]={ "modulus:", "publicExponent:", "privateExponent:",
"prime1:", "prime2:", "exponent1:", "exponent2:", "coefficient:"};
char* in = &private_decrypt;
char *token;
const char s[2] = " ";
char *token_2;
int k=0, size;
do {
if(k<8){
token = strstr(in,strings[k]);
size= strlen(token);
if (token){
*token = '\0';
}
switch (k) {
case 1:
strcat(in,"\0");
printf("k=%d:\n %s\n",k,in);
mpi_read_string(&rsaContext->N, 16, in);
break;
case 2:
token_2 = strtok_r(in, s, &in);
strcat(token_2,"\0");
printf("k=%d:\n %s\n",k,token_2);
mpi_read_string(&rsaContext->E, 16, token_2);
break;
case 3:
break;
case 4:
break;
case 5:
break;
case 6:
break;
case 7:
break;
}
//printf("k=%d \n%s\n",k,in);
in = token+strlen(strings[k]);
k=k+1;
}
else{
token= "NULL";
break;
}
}while(token!=NULL);
// Check Public key
if(rsa_check_pubkey(rsaContext)!=0){
printf("Reading public key error\n");
exit(0);
}
=====================================================================
Upon doing all this, when check the if the public key is load correctly or
not, I'm getting *"Reading public key error". *Any help, what I'm doing
wrong?
Regards,
Shariful Alam
Hello,
I found that, /programs/pkeyrsa_genkey.c creates a plaintext rsa private
key. Is there any way I can generate the keys in the same format from a
.pem format?
Regards,
Shariful Alam
Hi,
I'm getting the following errors printed:
tls : error : [2021/06/21 21:43:12.360] [id = 10]:
../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(4369):
mbedtls_ssl_handle_message_type() returned -30848 (-0x7880)
tls : error : [2021/06/21 21:43:12.360] [id = 11]:
../../src/../externals/mbedtls/mbedtls/library/ssl_tls.c(8335):
mbedtls_ssl_read_record() returned -30848 (-0x7880)
after a file is successfully downloaded. It looks like
MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY gets interpreted and printed as error.
How can I fix this? Is this a configuration thing or do I edit the
ssl_tls.c source code?
Thank you,
Ron
mbedtls 2.16.0
On 2021-08-16 11:11 a.m., Ron Eggler via mbed-tls wrote:
> Hi,
>
> I am working on a client where I need to login to a FTPS server
> (vsftpd). I establish the connection, exchange Hellos, certificate &
> key exchange and all seems succesful and are happening fine.
>
> I am able to send "PBSZ 0" to the server which gets acknowledged with
> "200 PBSZ set to 0." (as seen in Wireshark).
>
> Then, when it comes to sending "PROT P", I cannot see it encoded in
> Wireshark. it just says "Application Data" and the next frame reads
> "Alert (Level: Fatal, Description: Bad Record Mac)". I have
> investigated my code (mostly for differences between "PBSZ 0" and
> "PROT P" but came up empty) and have searched the web but have failed
> to find the resolution to my problem, as of yet. It seems obvious that
> the problem must be in my code but I seem to be unable to put my
> finger on it! I thought I should check if someone here may have any
> other hints that will help me resolve the problem.
>
> I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf,
> MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing
> any issues.
>
I have been able to resolve this. It was caused by usage of different
context structure pointers.
Hi,
I am working on a client where I need to login to a FTPS server
(vsftpd). I establish the connection, exchange Hellos, certificate & key
exchange and all seems succesful and are happening fine.
I am able to send "PBSZ 0" to the server which gets acknowledged with
"200 PBSZ set to 0." (as seen in Wireshark).
Then, when it comes to sending "PROT P", I cannot see it encoded in
Wireshark. it just says "Application Data" and the next frame reads
"Alert (Level: Fatal, Description: Bad Record Mac)". I have investigated
my code (mostly for differences between "PBSZ 0" and "PROT P" but came
up empty) and have searched the web but have failed to find the
resolution to my problem, as of yet. It seems obvious that the problem
must be in my code but I seem to be unable to put my finger on it! I
thought I should check if someone here may have any other hints that
will help me resolve the problem.
I have temporarily set "mbedtls_ssl_conf_authmode( &ctxt.conf,
MBEDTLS_SSL_VERIFY_NONE);" to make sure that the CA is not the causing
any issues.
Thank you!
