With mbedTLS set up as a streaming server (e.g. https), can it deal
with two attempts to connect that arrive in quick succession, so two
handshakes are occurring simultaneously?
David
I have a working Client code in which I use MbedTLS functions to send HTTPS GET request to my server. For sending data to the server, I use mbedtls_ssl_write(). But this call is blocking.
My goal is to make this function call (mbedtls_ssl_write()) non-blocking. What is the correct way to do it ?
I read the documentation and concluded that:
1. I have to set the bio callbacks using the mbedtls_ssl_set_bio() function where I have to pass the callback functions as parameters in this function call.
2. I have to set the SSL context as non-blocking using the mbedtls_net_set_nonblock() function call
3. I have used the default bio callbacks, named mbedtls_net_send and mbedtls_net_recv, which are defined in net_sockets.c
My question is:
After setting the default bio callbacks (mbedtls_net_send and mbedtls_net_recv) and setting the SSL context as non-blocking (mbedtls_net_set_nonblock) which function should I use for non-blocking write/read. Will it be mbedtls_ssl_write() and mbedtls_ssl_read() ? And will the call back functions (which are set using mbedtls_ssl_set_bio) be called when read/write completes?
Please help me with advice on how to implement non-blocking write/read using MbedTLS functions.
Thanks and Regards,
Sritam Paltasingh.
Hi,
PSA driver interface specification talks about "add_entropy" entry point.
Snippet pasted below.
https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv…
*A driver can declare an entropy source by providing a "get_entropy" entry
point. This entry point has the following prototype for a driver with the
prefix "acme":*
*psa_status_t acme_get_entropy(uint32_t flags,
size_t *estimate_bits,
uint8_t *output,
size_t output_size);*
However, in the current implementation of MbedTLS 3.x I don't see
this implemented . With the psa_crypto-init() what I observe is that if the
platform enables MBEDTLS_ENTROPY_HARDWARE_ALT then using "
mbedtls_hardware_poll(),
the entropy source can be provided.
Can you please confirm if this observation is correct and also let us know
if the <driver>_get_entropy() is planned to be implemented in near future ?
Regards,
Ruchika
This event has been canceled.
MBed TLS Technical Forum - Asia
Monday Jan 2, 2023 ⋅ 3am – 3:50am
Mountain Standard Time - Phoenix
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: MBed TLS Technical Forum - Asia
Time: Nov 8, 2021 10:00 AM London
Every 4 weeks on Mon, 20 occurrence(s)
Nov 8, 2021 10:00 AM
Dec 6, 2021 10:00 AM
Jan 3, 2022 10:00 AM
Jan 31, 2022 10:00 AM
Feb 28, 2022 10:00 AM
Mar 28, 2022 10:00 AM
Apr 25, 2022 10:00 AM
May 23, 2022 10:00 AM
Jun 20, 2022 10:00 AM
Jul 18, 2022 10:00 AM
Aug 15, 2022 10:00 AM
Sep 12, 2022 10:00 AM
Oct 10, 2022 10:00 AM
Nov 7, 2022 10:00 AM
Dec 5, 2022 10:00 AM
Jan 2, 2023 10:00 AM
Jan 30, 2023 10:00 AM
Feb 27, 2023 10:00 AM
Mar 27, 2023 10:00 AM
Apr 24, 2023 10:00 AM
Please download and import the following iCalendar (.ics) files to your
calendar system.
Weekly:
https://linaro-org.zoom.us/meeting/tJ0kc-GsqDktHNGa8CWl6wJ7je6CKD-5zgh8/ics…
Join Zoom Meeting
https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT…
Meeting ID: 999 4846 2765
Passcode: 196117
One tap mobile
+12532158782,,99948462765# US (Tacoma)
+13462487799,,99948462765# US (Houston)
Dial by your location
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 999 4846 2765
Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
Guests
Don Harbin - creator
nnac123(a)gmail.com
santosdanillo(a)gmail.com
schoenle.thomas(a)googlemail.com
kris.kwiatkowski(a)pqshield.com
psa-crypto(a)lists.trustedfirmware.org
mbed-tls(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Dear sir/madam
I have following queries regarding implementation of MBED CRYPTO Libraries :
1) How crypto libraries files could be used on baremetal with no entropy
source(cross compilation )?
2) How asymmetric cryptographic operations like RSA , RNG , EC ,DSA etc ,
could be implemented on baremetal without entropy , seed provisions ?
3) If i want to use some custom PRNG and entropy , then how the respective
contexts structures could be filled ?
Thanks & Regards,
*Prashant Tripathi*
Hi Mbed TLS users,
We are pleased to announce the release of Mbed TLS versions 3.3.0 and 2.28.2.
These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-3.3.0 and https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.2 ).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
The releases are available from
https://github.com/Mbed-TLS/mbedtls/releases
Dave Rodgman
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
I am using mbedtls_x509write_csr_set_subject_name API from mbedtls to set the subject name.
I wanted to set the arbitrary old value in my certificate for e.g.
ffeBgt9jDHhBwPDANgtT7R/1.3.6.1.4.1.37244.2.1=FFF2/1.3.6.1.4.1.37244.2.2=8001
In this case ffeBgt9jDHhBwPDANgtT7R is the CN
And 1.3.6.1.4.1.37244.2.1 is an arbitrary OID which has a value of FFF2 similar to the second arbitrary OID.
I am able to do this through openssl commands, but while doing it through mbedtls, when I pass it as a string then mbedtls considers the whole string as CN which Is not my intention.
Please fine the asn1 parsing of the CSR as below
CSR generated through mbedtls:
18:d=5 hl=2 l= 3 prim: OBJECT :commonName
23:d=5 hl=2 l= 76 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R/1.3.7.1.4.1.37466.2.1=FFF2+1.3.7.1.4.1.37466.2.2=8001
101:d=3 hl=2 l= 11 cons: SET
103:d=4 hl=2 l= 9 cons: SEQUENCE
Target CSR ( done thorough openssl):
14:d=4 hl=2 l= 29 cons: SEQUENCE
16:d=5 hl=2 l= 3 prim: OBJECT :commonName
21:d=5 hl=2 l= 22 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R
45:d=3 hl=2 l= 20 cons: SET
47:d=4 hl=2 l= 18 cons: SEQUENCE
49:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.1
61:d=5 hl=2 l= 4 prim: UTF8STRING :FFF2
67:d=3 hl=2 l= 20 cons: SET
69:d=4 hl=2 l= 18 cons: SEQUENCE
71:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.2
83:d=5 hl=2 l= 4 prim: UTF8STRING :8001
89:d=2 hl=2 l= 89 cons: SEQUENCE
91:d=3 hl=2 l= 19 cons: SEQUENCE
93:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
102:d=4 hl=2 l= 8 prim: OBJECT :prime256v1
Am I missing something here? Do I need to provide the CN in a different way to get the intended result?
I found an open issue https://github.com/Mbed-TLS/mbedtls/issues/4886, could it be related to this?
Any help would be appreciated.
Thanks and Regards,
Aditya
Hi All,
Some websites crash MbedTLS, in
void mbedtls_ecp_point_free( mbedtls_ecp_point *pt )
{
if( pt == NULL )
return;
mbedtls_mpi_free( &( pt->X ) );
mbedtls_mpi_free( &( pt->Y ) );
mbedtls_mpi_free( &( pt->Z ) );
}
It crashes in the last function call of the three above.
Thread #1 [main] 1 [core: 0] (Suspended : Signal :
SIGTRAP:Trace/breakpoint trap)
HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22
<signal handler called>() at 0xffffffed
0x3810180
mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a
0x81030100
It crashes properly i.e. invalid opcodes etc.
There is a fair bit on google with others having gone down the same
road, never resolved.
One site which does it is socata.org but quite a few others do it.
Probably 10% of "major name" websites cause it to crash.
It may have been undiscovered for a long time, or ever, because most
MbedTLS clients are connecting to specific private servers only.
People aren't using it to connect to microsoft.com (which doesn't
actually crash but the handshake returns 0x2700 which can be
investigated).
There is a Windows build of MbedTLS (v2.16.2) which seems to work in
the crashing cases. Stepping through this in Cube IDE (32F417) it
looks like the crash is due to a buffer being filled with random
numbers. The guy working on this is contactable only on Monday
afternoons so I am a bit screwed :) He said he found something about
that buffer, or maybe a corrupted function pointer.
But as I said this issue has come up before according to numerous
online searches and maybe someone can recognise it.
Hardware AES is enabled but this occurs with software AES also. No
other 32F417 hardware crypto features are used, other than its random
number generator.
TLS is v2.16.2.
Thank you in advance for any pointers.
Peter
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Dec 5 at 10:00am UK time*. Invite details can be
found on the online calendar here
<https://www.trustedfirmware.org/meetings/>.
As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
Mbed TLS is planning to move to a new code style by the end of this year. The proposed new style is currently being discussed in the GitHub pull request:
https://github.com/Mbed-TLS/mbedtls/pull/6591
If you have any feedback on this new style, or you think we should tweak it, feel free to comment on the pull request. We will take your thoughts into account when we decide on the final style.
Discussions will continue until the evening of THIS FRIDAY (UK time).
Many thanks,
David Horstmann for the Mbed TLS Team
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello everyone,
We observed a strange behavior in the mbedTLS client, when client authentication is requested by the TLS server. This behavior was observed in the newer version 3.0.0 as well as in older versions.
The scenario is the following: The server selects a ciphersuite e.g. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and sends a CertificateRequest message that only includes the ecdsa_secp256r1_sha256 signature algorithm.
However, the mbedTLS client simply ignores the requested hash function and uses ecdsa_secp256r1_sha384 for the signature in the ClientVerify.
Then, the server complains since the signature does not match with the requested signature algorithm and sends a handshake failure.
It seems that mbedTLS does not store the requested signature algorithms/hash function from the CertificateRequest and always uses the hash function from the selected ciphersuite.
In the ssl_write_certificate_verify function, we find the following comment:
/*
* digitally-signed struct {
* opaque handshake_messages[handshake_messages_length];
* };
*
* Taking shortcut here. We assume that the server always allows the
* PRF Hash function and has sent it in the allowed signature
* algorithms list received in the Certificate Request message.
*
* Until we encounter a server that does not, we will take this
* shortcut.
*
* Reason: Otherwise we should have running hashes for SHA512 and
* SHA224 in order to satisfy 'weird' needs from the server
* side.
*/
Is this a known problem and is there any fix available?
Cheers,
Simon Nachtigall
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Nov 7 at 10:00am UK time*. Invite details can be
found on the online calendar here
<https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman, cc'd, know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi all,
I'd like to know if there is some way to retrieve the currently available number of bytes of application data without calling mbedtls_ssl_read()?
I'm writing a "TLS socket" for higher layers to use and would like to notify them when new application data is available, tell them how much it is, but leave it up to them when and how much to retrieve.
I'd like to prevent having to buffer all application data inside my TLS socket, because that would mean copying it once from mbedtls' buffer to my socket and then again from there to the application whenever it actually requests the data.
After a quick look into the sources, it seems like, if at all, this might be possible for single records. But all related fields are private and I could not find any API for this.
Issue #551 [1] seems related, but is more about peeking into the application data, while I would be fine with knowing just the size of available application data.
Thanks for any hints on how I could achieve this.
Best regards,
Jan
[1] https://github.com/Mbed-TLS/mbedtls/issues/551
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Hello,
Summary: I am soliciting feedback about builds of Mbed TLS where *there
is both a PSA implementation and the built-in software implementation of
the same algorithm, by design, *and the PSA implementation isn't just
calling the built-in implementation because the two have different
characteristics, each desirable in some context. Please read this
message if you are doing this or considering it. Feel free to ignore
otherwise.
For example, both MBEDTLS_SHA256_C and MBEDTLS_PSA_ACCEL_ALG_SHA_256 are
enabled, so that calls to mbedtls_md_xxx() use the software
implementation and calls to psa_hash_xxx() use the hardware accelerator
via the PSA driver. And this is deliberate: there is a reason why
mbedtls_md_xxx() must not call the PSA driver.
In most cases, this is not desirable: if there's an accelerator, why not
use it? And we're working to allow getting rid of the software
implementation in more and more cases. Ultimately, PSA will be the only
crypto interface in Mbed TLS, so all interfaces to calculate SHA-256
will go through psa_hash_xxx() and therefore will dispatch the call to
the driver if there is one. This will be an API break, since it will
require calling psa_crypto_init() before performing any cryptography.
Currently we are planning to introduce this requirement in Mbed TLS 4.0.
But it is currently possible to have dual algorithm support, and I can
think of unusual cases where it might desirable.
Scenario 1, with accelerator drivers: there is a driver, but it can only
be used after some initialization. The application needs to use the
algorithm before calling psa_crypto_init(), so it calls the legacy
interface. After psa_crypto_init() has been called, the application
would like to use the driver as much as possible. A typical use case is
a bootloader which wants to verify a signature before initializing the
random generator, so it calls mbedtls_md_xxx() and mbedtls_rsa_xxx().
Scenario 1 is clearly desirable, and for that we have a planned
solution, which is staged initialization. The bootloader will be able to
(1) initialize drivers, (2) perform a hash calculation, (3) initialize
the keystore, (4) verify a signature, all without initializing the RNG.
We won't make psa_crypto_init() mandatory until this feature is implemented.
Scenario 2: with a cryptography service. This is a build of Mbed TLS
with MBEDTLS_PSA_CRYPTO_CLIENT, so all psa_xxx() calls call the service.
But, for some reason, there is also a local implementation of some
cryptography algorithms. So you can call mbedtls_md() to calculate a
hash even before the connection to the service has been established. Or
maybe you want to call mbedtls_md() for short messages and
psa_hash_compute() for long messages, because the crypto service has a
faster implementation but the communication overhead offsets the gain
for short messages.
We are currently working on improving support for PSA drivers, and in
particular, saving code size by eliminating more unnecessary code when a
driver is present, and increasing the set of APIs that benefit from
drivers. The obvious way to do that is to make all cryptography calls
(especially from X.509 and TLS) go via the PSA interface, but we can't
do that yet due to the need to have initialized the keystore and RNG. We
are considering routing /certain/ crypto calls via PSA, in a way that
would break scenario 2, and would also break scenario 1 in some cases,
but not for hashes or signature verification.
If, for example, in Mbed TLS 3.4, mbedtls_md() starts calling
psa_hash_(), would this break your code? Are you in scenario 1, scenario
2, or some other variant I haven't thought of?
If so, *please reply to this message and let us know what your needs
are*. Feel free to reply to me in private if you don't want to discuss
this publicly (I won't share directly outside Arm, but the eventual
design might leak information about the unusual scenario).
If we don't hear objections, there is a chance that a future Mbed TLS
3.x will break scenarios 1 and 2. If we do hear objections, we'll work
to keep the current behavior or arrange a migration path.
Best regards,
--
Gilles Peskine
Mbed TLS developer
I have port mbedtls 2.28.0 into my platform and am able to connect to a few websites in PKI mode. But after enabling MBEDTLS_USE_PSA_CRYPTO & MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG, with everything else stay the same, I can't connect to the same websites anymore. in the working case (no MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server responds with "Change Cipher Spec, Encrypted Handshake Message". In the broken case (with MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server doesn't respond with "Change Cipher Spec, Encrypted Handshake Message". I don't know how to debug the issue, any suggestion what my cause the server to drop off at the last step?
I may need TLS 1.3 support which I believe arrived in 2.28, or maybe a
bit later.
I don't want to change to TLS 3 just yet. It looks like many changes.
My target is "OK" on FLASH (150k of the 350k total code size) but is
tight on RAM (after allocating 50k for the MbedTLS heap, we have just
20k RAM left).
Ideally I would like the very last version of v2.
The problem just found is that Cloudflare is asking for TLS 1.3 which
MbedTLS 2.16 does not support. But it may be that Cloudflare can fall
back and the problem is elsewhere.
Many thanks for any input.
Hi,
This is an updated post from https://github.com/Mbed-TLS/mbedtls/issues/6464,
which should be posted in mbedtls mail list.
My question is how to significantly improve SHA256 performance on big files
(regardless of architectures).
*=== Updates*
I use same code with mbedtls-3.1.0 to run tests in x86, and performance is
still downgraded.
Mbed TLS version (number or commit id): *3.1.0*
Operating system and version: * Centos-8.5, CPU 11900K*
Configuration (if not default, please attach mbedtls_config.h):
Compiler and options (if you used a pre-built binary, please indicate how
you obtained it): *gcc/g++ 8.5*
Additional environment information:
*Test files and performance*
CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha256 *5 sec*
CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha256 *66 sec*
Also, as advised I try to turn on "MBEDTLS_SHA256_USE_A64_CRYPTO_IF_PRESENT
" and "MBEDTLS_SHA512_USE_A64_CRYPTO_IF_PRESENT" using mbedtls-3.2.0 in M1,
but compiler reported the following error:
CMake Error at library/CMakeLists.txt:257 (add_library):
Cannot find source file:
psa_crypto_driver_wrappers.c
Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h
.hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc
CMake Error at library/CMakeLists.txt:257 (add_library):
No SOURCES given to target: mbedcrypto
Thanks for your help.
*=== Original message at github*
Summary
sha256() and sha1() incurs significant overhead on big files(~1G above). *This
might not be an issue*, and I'm looking for an efficient way to calculate
hash on big files.
System information
Mbed TLS version (number or commit id): 3.1.0
Operating system and version: M1 OSX
Configuration (if not default, please attach mbedtls_config.h):
Compiler and options (if you used a pre-built binary, please indicate how
you obtained it): Clang++
Additional environment information:
Expected behavior
Fast calculation of big files in less than 1 second
Actual behavior
Test files:
CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha1 *3.3 sec*, sha256 *5.9
sec*
CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha1 *40 sec*, sha256 *78
sec*
Steps to reproduce
ISO files can be downloaded at:
http://ftp.iij.ad.jp/pub/linux/centos-vault/8.5.2111/isos/x86_64/
Make sure use fast disk, say nvme, to store ISO files, or else loading big
files could take lots of time. Also use user from time command to measure
performance.
Workable code of sha256:
string test_sha256(string file_path)
{
mbedtls_sha256_context ctx;
FILE *fp;
string output;
int BUFFER_SIZE = 4096;
uint8_t buffer[BUFFER_SIZE];
size_t read, k_bytes;
uint8_t hash[32];
mbedtls_sha256_init(&ctx);
mbedtls_sha256_starts(&ctx, 0);
fp = fopen(file_path.c_str(), "r");
if (fp == NULL)
{
mbedtls_sha256_free(&ctx);
return output;
}
while ((read = fread(buffer, 1, BUFFER_SIZE, fp)))
{
mbedtls_sha256_update(&ctx, buffer, read);
}
mbedtls_sha256_finish(&ctx, hash);
mbedtls_sha256_free(&ctx);
fclose(fp);
// update hash string, omit here
return output;
}
Hi All,
There are machines out there for testing servers but I don't know of
one which can be used for testing a client.
This is a tricky area. For example I have a board running, LWIP and
MbedTLS, uploading little test files to two sites.
One was running EC and AES256. It worked fine.
The other was running RSA and AES256 but didn't work, and after some
work it was found that its certificate chain was running SHA-1 on the
top level certificate, dated 2006. This is actually a major name on
the internet! And we didn't have SHA-1 enabled because it is supposed
to be deprecated.
I wonder if there is some practical way to test out all this. We can
probably enable all the MbedTLS crypto options (TLS is taking up 150k
out of 350k of code for the whole product, but we can probably throw
in some more) but testing them is something else.
There is a test suite in TLS but it needs to be embedded in the
product itself. Has someone implemented that code on a server
somewhere?
Thank you in advance for any pointers.
Peter
I meet a problem when I call function `psa_crypto_init`, it return error code -148 that was PSA_ERROR_INSUFFICIENT_ENTROPY.
I track this function step by step and found it caused by MBEDTLS_ERR_ENTROPY_NO_SOURCES_DEFINED. Code in entropy.c, if( ctx->source_count == 0 ), return this error.
My question:
I run code on Ubuntu, it runs well. But in some arm board, it returns this error. Why this count will be 0 sometimes? What is the root cause of this error.
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi,
I have developed a TLS and EST client application. Where the EST server issues the certificate in PKCS#7 format. It seems mbedtls library not support certificates in PKCS#7 format.
Is there any plan to support PKCS#7 in future?
Thanks,
Gopi Krishnan