AES implementation without a TLS or SSL library #7512
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7512 +/- ##
==========================================
- Coverage 98.29% 98.28% -0.01%
==========================================
Files 154 154
Lines 19989 19989
==========================================
- Hits 19648 19647 -1
- Misses 341 342 +1
Continue to review full report at Codecov.
|
nickovs
force-pushed
the
native_aes
branch
2 times, most recently
from
52171e7
to
713069d
Compare
Thanks @nickovs Just curious what the above means... is it not possible to just use (say) mbedtls' AES (or SHA) algorithms without linking in any other parts of the TLS stack. I agree it's unfortunate to require the whole mbedtls submodule just so rp2 can have crypto (but this doesn't seem too much of a burden?). |
|
@jimmo It may well be possible to alter the build system to pick and choose which bits of mbedtls get used, but there seems to be a fair amount of internal dependency. Coupled with the fact that right now neither mbedtls nor axTLS have been ported to run on the rp2 version of micropython I thought it would be helpful to have a stand-alone implementation. |
|
Hello, your PR seems to be making changes to the submodules lib/mbedtls, lib/pico-sdk and lib/tinyusb, I don't think this is intentional. |
|
@iabdalkader I think I have fixed the problem with the submodules. For some reason my master branch had its submodules out of sync with upstream. |
|
Oh no, I'm very sorry @nickovs that I completely lost track of this PR! And then I went ahead and added What you have here is nice and clean, a good addition for ports that don't have a full TLS library. Do you think this is still useful and worth adding? It's actually pretty easy to include mbedtls in the build now (either Makefile based or CMakeLists.txt), although it is rather large, it added about 14k to the rp2 firmware to enable |
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
Currently
ucryptolibonly provides an AES implementation if one of the SSL or TLS libraries is included. This means that AES is unavailable on ports that don't support a full TLS stack and, on those ports that do have a TLS stack, it is necessary to have the entire stack in order to support AES. There is already a fallback implementation of SHA256 foruhashlib; this PR provides a fallback implementation of AES for ports where no TLS stack is included.The AES implementation here was built from scratch with a view to being portable, and to optimising runtime memory needs over code size and code size over pure performance (although the performance is in fact pretty good). It has been tested against the test vectors in NIST Special Publication 800-38A as well as passing the AES tests in
tests/extmod/ucryptolib_*.py.The code has been tested on the Unix (macOS), esp32 and rp2 ports; it should probably be tested on other ports before merging. Since the rp2 port does not currently have any AES implementation, the PR enables the new implementation on that port by default.