Hi Youssouf,
I think you're looking for mbedtls_mpi_write_file() - just pass NULL as the file argument to write to stdout. You can use the radix argument to print out hex or decimal.
Regards,
Manuel.
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of youssouf sokhona via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 25 August 2020 15:40
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Set an MPI and print it
Hi everyone, I think you all are fine.
I am a beginner on mbedtls, and I wanted to set a dhm context. So, at first, I just want to set the value of the prime P, and the generator G. So to that I wrote the function below : [cid:image001.png@01D67AF5.D43FDE60]
To check if it is correctly set, I wanted to print it to see. However, it is not the case. Do you know how to set and print the value ?
Thanks, and have a good day
Best regards, YS
Hi everyone, I think you all are fine.
I am a beginner on mbedtls, and I wanted to set a dhm context. So, at first, I just want to set the value of the prime P, and the generator G. So to that I wrote the function below : [cid:image001.png@01D67AF5.D43FDE60]
To check if it is correctly set, I wanted to print it to see. However, it is not the case. Do you know how to set and print the value ?
Thanks, and have a good day
Best regards, YS
Hello everybody, I hope you are going well
I am creating a diffie Hellman key exchange program, so I am using functions like « mbedtls_dhm_init() » or « mbedtls_ctr_drbg_init() « for example. However, even if I defined the CTR_DRBG & the DHM_C module in the config.h file, and the header in my C file, I Always have error like that :
[cid:image002.png@01D6770C.20370D40]
Can someone help me to find out where does it come from ? Because I don’t know at all.
Thanks, and have a good day
Hi all,
I am placing into review a patch (
https://github.com/ARMmbed/mbedtls/pull/3579) which replaces some
invalid size printf format specifiers, mostly for size_t. This patch
utilises %zu and %hhu, both of which were only introduced in C99, which
I know caused some issues with compiler compatibility at the time. The
problem with printf and size_t as most will know, is that its a
different size in 32 bit and 64 bit, which is what %z was introduced to
safely fix.
My question is to whether there is anyone on the list that is using a
compiler that might not handle these specifiers, for whom this patch
would presumably be something of an issue. I am admittedly hoping this
is not the case, given the age of the spec, but thought it best to ask.
Thanks in advance,
Paul.
Hi Murat
What you request may be possible with invasive changes but it is not a design goal for the PSA Cryptography API implementation in Mbed TLS to be completely replaced with an alternative implementation, while allowing re-use of the Mbed TLS build system and tests.
The focus instead is to develop and implement a PSA Cryptoprocessor Driver Interface, which will allow drivers for custom secure environments to be plugged into the core PSA Cryptography API implementation in Mbed TLS. An early version of the specification of that interface can be found here:
https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…
That specification and its implementation is under active development. Let us know if you would like to get involved.
Regards
Dan.
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of Murat Cakmak via mbed-tls
Sent: 14 August 2020 13:34
To: mbed-tls(a)lists.trustedfirmware.org
Subject: [mbed-tls] Custom PSA API Implementation for mbedTLS tests
Hi all,
We have implemented the PSA Functional API for a custom secure environment which passes PSA Arch tests.
Now we would like to run mbedtls tests (make check) on the PSA API if possible.
When we run "make check", it includes and compiles library/psa_crypto.c file for mbedTLS's PSA API Implementation.
Herein, we would like to compile our own psa_crypto.c implementation, does mbedtls build system allow us to include custom PSA API Implementation to run tests?
Thank you.
Murat
Greetings,
I am new to the list, please do excuse me, in case of any list
specific etiquette issues.
Trying to use a 1.6.1 release with a Cortex M7 port, specifically a STM32H7.
After enabling MBEDTLS_ENTROPY_HARDWARE_ALT, did implement
mbedtls_hardware_poll()
It looks thus, and it does appear to work from a hardware perspective:
/**
* mbedtls_hardware_poll()
* Read random data from the Hardware RNG for entropy applications
*/
int mbedtls_hardware_poll(void *arg,
unsigned char *ent_buf,
size_t count,
size_t *ent_len)
{
register uint8_t i = 0;
uint32_t rand;
if (!LL_RNG_IsEnabled(RNG))
LL_RNG_Enable(RNG); /* Enable Random Number Generator */
for (i = 0; i < count; i++) {
while (!LL_RNG_IsActiveFlag_DRDY(RNG)) { } /* Wait for DRDY
flag to be raised */
if ((LL_RNG_IsActiveFlag_CECS(RNG)) ||
(LL_RNG_IsActiveFlag_SECS(RNG))) { /* Check error, if any */
/* Clock or Seed Error detected. Set Error */
printf(" (%d) %s: Clock/Seed Error!\r\n", __LINE__, __FUNCTION__);
}
rand = LL_RNG_ReadRandData32(RNG); /* Read RNG data */
memcpy(&(ent_buf[i * 4]), &rand, 4); /* *ent_len += 4 */
}
LL_RNG_Disable(RNG); /* Stop random numbers generation */
*ent_len = ((i + 1) * 4);
printf(" (%d) %s: Random Words: %d Word: %04d\r\n",
__LINE__,
__FUNCTION__,
count,
rand);
return 0;
}
The code which causes the problem is this, in my tls_init()
int tls_init(void)
{
int ret;
/* inspired by https://tls.mbed.org/kb/how-to/mbedtls-tutorial */
const char *pers = "SYS-LWH7";
printf(" (%d) %s: Initializing\r\n", __LINE__, __FUNCTION__);
/* initialize descriptors */
mbedtls_ssl_init(&ssl);
printf(" (%d) %s: SSL initialize\r\n", __LINE__, __FUNCTION__);
mbedtls_ssl_config_init(&conf);
printf(" (%d) %s: SSL Config initialized\r\n", __LINE__, __FUNCTION__);
mbedtls_x509_crt_init(&cacert);
printf(" (%d) %s: x509 CRT initialized\r\n", __LINE__, __FUNCTION__);
mbedtls_ctr_drbg_init(&ctr_drbg);
printf(" (%d) %s: DRBG initialized\r\n", __LINE__, __FUNCTION__);
mbedtls_entropy_init(&entropy);
printf(" (%d) %s: Entropy initialized\r\n", __LINE__, __FUNCTION__);
ret = mbedtls_ctr_drbg_seed(&ctr_drbg,
mbedtls_entropy_func,
&entropy,
(const unsigned char *) pers,
strlen(pers));
if (ret) {
LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE,
("failed !\n mbedtls_ctr_drbg_seed returned %d\n",
ret));
printf(" (%d) %s: DRBG seed failed, ret=%d\r\n", __LINE__,
__FUNCTION__, ret);
return -1;
}
printf(" (%d) %s: DRBG seed returned:%d\r\n", __LINE__, __FUNCTION__, ret);
/**
* The transport type determines if we are using
* TLS (MBEDTLS_SSL_TRANSPORT_STREAM) or
* DTLS (MBEDTLS_SSL_TRANSPORT_DATAGRAM).
*/
ret = mbedtls_ssl_config_defaults(&conf,
MBEDTLS_SSL_IS_CLIENT,
MBEDTLS_SSL_TRANSPORT_STREAM,
MBEDTLS_SSL_PRESET_DEFAULT);
if (ret) {
LWIP_DEBUGF(MQTT_APP_DEBUG_TRACE,
("failed !\n mbedtls_ssl_config_defaults returned %d\n\n",
ret));
printf("(%d) %s: SSL config defaults failed, ret=%d\r\n",
__LINE__, __FUNCTION__, ret);
return -1;
}
printf("(%d) %s: SSL config defaults returned:%d\r\n", __LINE__,
__FUNCTION__, ret);
ret = mbedtls_x509_crt_parse(&cacert,
(const unsigned char *)test_ca_crt,
test_ca_crt_len);
if (ret)
printf(" (%d) %s: failed!\n mbedtls_x509_crt_parse returned
%d\r\n", __LINE__, __FUNCTION__, ret);
else
printf(" (%d) %s: mbedtls_x509_crt_parse returned %d\r\n",
__LINE__, __FUNCTION__, ret);
mbedtls_ssl_conf_ca_chain(&conf, &cacert, NULL);
mbedtls_ssl_conf_authmode(&conf, MBEDTLS_SSL_VERIFY_REQUIRED);
/**
* The library needs to know which random engine
* to use and which debug function to use as callback.
*/
mbedtls_ssl_conf_rng(&conf, mbedtls_ctr_drbg_random, &ctr_drbg);
mbedtls_ssl_conf_dbg(&conf, my_debug, stdout);
mbedtls_ssl_setup(&ssl, &conf);
}
The output of which looks thus, in a serial terminal:
(1217) print_dhcp_state: Try connect to Broker
(174) tls_init: Initializing
(178) tls_init: SSL initialize
(181) tls_init: SSL Config initialized
(184) tls_init: x509 CRT initialized
(187) tls_init: DRBG initialized
(190) tls_init: Entropy initialized
(1027) mbedtls_hardware_poll: Random Words: 128 Word: -558876895
Any thoughts/ideas, what could be wrong ?
Any kind soul in here ?
Thanks,
Manu
Hi Simon,
Indeed while the migration is underway things can be a bit confusing, so let me try to clarify:
* releases can be found at: https://github.com/ARMmbed/mbedtls/releases - near the top you'll alwys find the latest development release followed by the latest LTS releases. At this point it is unclear if releases are going to stay on github or if they would move to trustedfrimware.org in the future, but if anything changes, we'll announce it.
* announcements about new releases and other important project events are made on the new Mbed-tls-announce mailing-list: https://github.com/ARMmbed/mbedtls/releases - if you're already subscribed to mbed-tls (this list), you don't need to subscribe to the "announce" mailing list in addition, as any post to "announce" is automatically cross-posted here ("announce" is for people who want a lower volume list).
* I don't think we're currently making announcements about upcoming releases, but I know we considered that. Unfortunately I don't remember the details and the colleague who was working on improving our release process is on leave now. But it we start making such announcements, they'll be on the "announce" list.
* We're currently planning 2.16.8 early in September.
* If you have a large number of products deployed that depend on Mbed TLS (or indeed any other tf.org project) and would like to be notified in advance of upcoming security fixes, please see the following pages: https://developer.trustedfirmware.org/w/mbed-tls/security-center/https://developer.trustedfirmware.org/w/collaboration/security_center/repor…https://developer.trustedfirmware.org/w/collaboration/security_center/trust…
I hope this answers your questions, and feel free to ask otherwise.
Manuel.
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Simon Leet via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 14 August 2020 15:13
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] LTS roadmap and announcement channel?
Hi folks,
I understand that https://tls.mbed.org/ has migrated under the umbrella of https://www.trustedfirmware.org/ but it’s not clear where I should turn to for information about the updates to the LTS versions. The https://tls.mbed.org/tech-updates blog used to announce LTS branch updates but seems defunct as of 2.16.7, and I can’t find equivalent information in https://developer.trustedfirmware.org/w/mbed-tls/roadmap/, https://github.com/ARMmbed/mbedtls/projects/2 or the generic https://www.trustedfirmware.org/blog/.
Is there a new channel for information about upcoming LTS mbedtls releases so that users can plan their appropriate upgrade cycles? E.g. when is 2.16.8 roughly expected to be released? Is the new model for monitoring release announcements reliably going to be as a new tag on https://github.com/ARMmbed/mbedtls/tags?
-Simon
