Good morning to all,
I am currently trying to perform RSA encryption, so I am using a file containing a public key (generated by OpenSSL) to do this.
So at the beginning I use the "mbedtls_pk_parse_keyfile" function to read it, as you can see on the image below. Unfortunately, I find the following error : ERROR 3E00 : Read/write of file failed.
Do someone have an idea of why I have this error ? Or should I change my way to read this file ?
Thanks a lot, have a nice Weekend
[cid:image002.png@01D68839.7B058100]
Hi,
Unrelated comment from my side, adding on to Manuel's comment:
It appears that ST supplies a binary blob which does make use of their
hardware crypto accelerator.
https://www.st.com/en/embedded-software/x-cube-cryptolib.html
Cheers,
Manu
On Wed, Sep 9, 2020 at 1:21 PM Manuel Pegourie-Gonnard via mbed-tls
<mbed-tls(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well.
>
> Regards,
> Manuel.
> ________________________________
> From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
> Sent: 09 September 2020 08:32
> To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
> Subject: [mbed-tls] Query related to ARM - MbedTLS
>
> Hi,
>
> I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University.
>
> I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+.
>
> Looking forward to hearing from you.
>
>
> Best regards,
> Hafiz Areeb Asad
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi,
On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well.
Regards,
Manuel.
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 09 September 2020 08:32
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Query related to ARM - MbedTLS
Hi,
I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University.
I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+.
Looking forward to hearing from you.
Best regards,
Hafiz Areeb Asad
Hi,
I hope you are doing well. I am using the mbedTLS AES library in my
projects, part of my master thesis at Uppsala University.
I would like to know whether the mbedTLS AES library uses any assemble
specific code for operations? I am using this library on Cortex-M23 and
Cortex M0+.
Looking forward to hearing from you.
Best regards,
Hafiz Areeb Asad
Hello,
As you may be aware, there is work in progress to implement support for
hardware drivers in Mbed TLS when using the PSA API. These are direct
calls from the PSA frontend layer to driver code, without going through
mbedtls_xxx APIs and the ALT implementations. The specifications are the
psa-driver-*.md files in
https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed and
you can watch the work in progress in the “Unified driver interface: API
design and prototype” epic
https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 .
When an algorithm is implemented in hardware, in most cases, it is
unnecessary to include a software implementation, and it should be
possible to exclude the software implementation from the build to keep
the code size down. Unfortunately the current Mbed TLS configuration
mechanism does not support this, because it does not distinguish “I want
AES” from “I want mbedtls_aes_xxx”. So we need new compile-time options
to convey “I want PSA_KEY_TYPE_AES in my application but I don't care
whether it's done in hardware or mbedtls_aes_xxx”.
We are going to implement a configuration mechanism to select which
cryptographic algorithms are included in the PSA interface in a build of
Mbed TLS. It will rely on #define statements, like the existing
config.h, but with different naming conventions for PSA. You can see the
specification proposal at https://github.com/ARMmbed/mbedtls/pull/3628 .
Feedback is welcome. We're likely to merge this pull request soon, but
even after it's merged I'll keep watching comments, or you can post
feedback on the mailing list, or raise an issue on GitHub if you have a
specific feature request.
A major difference between the current MBEDTLS_xxx_C configuration and
the new PSA_WANT_xxx configuration is that PSA_WANT_xxx is additive: if
PSA_WANT_xxx depends on some other feature, enabling PSA_WANT_xxx will
automatically enable that feature in most cases (the exception being
when there's more than one way to enable the dependent feature, e.g.
when a hash algorithm is needed but it doesn't matter which hash). This
is in contrast with the current strict mechanism where enabling
MBEDTLS_xxx_C is an error if it depends on some other feature that isn't
enabled. We haven't decided yet, but we're thinking of changing to an
additive mechanism for the whole Mbed TLS configuration in Mbed TLS 3.0.
If you want to watch the implementation work in progress, it will be
under the “Driver Interface: Removing unused code” epic
https://github.com/ARMmbed/mbedtls/projects/2#column-9449707 .
Note that the #define-based mechanism is somewhat experimental and we
won't commit yet about its long-term stability in Mbed TLS. It is likely
to be complemented by a JSON-based mechanism in the future. This JSON
mechanism would be similar to the proposed mechanism for drivers and
would allow finer granularity (for example, RSA verification without RSA
signature). Arm is considering standardizing the (as yet non-existent)
JSON mechanism as a PSA specification.
Best regards,
--
Gilles Peskine
Mbed TLS developer (and PSA crypto architect)
Hi,
I hope everyone is doing well. I am a beginner on mbedtls and cryptography.
I hope you will understand if there is a lack of understanding or a rookie
mistake from my part.
So, My goal is to do a key-encryption key. I have an *RSA* private key file
"*private.pem*" generated by OpenSSL. I want to encrypt the content of
this "private.pem" with *AES* *encryption* and followed by *AES decryption
*on the encrypted data.
To do that, I read the "private.pem" file into a buffer and perform AES
encryption. The problem is when I perform the AES decryption operation I
get something else instead of the original "private.pem" data. I have a
working example of AES encryption/decryption working on plaintext
perfectly. So, I guess there is a flaw in my understanding of
encryption/decryption of byte64 encoded string.
Can someone please suggests me how can I encrypt RSA private key with AES?
Thanks,
Shariful
Mbed TLS version 2.24.0, 2.16.8 and 2.7.17 have been released recently. Version 2.7.17 is incorrectly marked as the latest release by github. Since this happens automatically based on the commit creation dates, this can’t be fixed until the next release.
We have extended the release notes of 2.7.17 to warn about this and changed the download links on the website.
We would like to confirm that version 2.24.0 is the latest release and the other two are the patch releases for the 2.16 and 2.7 long term support branches.
My apologies for the inconvenience and thank you for your support!
Best regards,
Janos
(On behalf of the Mbed TLS team)
--
Mbed-tls-announce mailing list
Mbed-tls-announce(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce