Deduplicate crypto libraries, saving ~49KB flash

[ViezeVingertjes]

Fixes a stack overflow in ed25519_verify() by making large local variables static, removing the need for rweather's Ed25519::verify() workaround.

Only vendors the AES128+SHA256 subset of rweather/Crypto instead of all 37 files.

No issues observed so far. Additional testing and confirmation are welcome. This change frees up stack space for future improvements and improves support for resource-limited devices.

[weebl2000]

Nice improvement — vendoring the minimal subset is clean and the stack savings are real (~1.8KB moved to BSS). One concern about the static locals in ge.c.

[JosiahWI]

The code looks great. I'm giving my capstone team an opportunity to build this PR and test it and then I'll approve. :)

[JosiahWI]

The reduction in program size from this PR will be very useful for my school capstone. One of my teammates has built our branch with it and confirmed that the Flash saving makes it possible to fit the program on an nRF52840 Dongle alongside an InternalFS and DFU bootloader.

Edit: The above is only possible if you are not using a display.

[nextgens]

I'd go even further than this: we don't keep key schedules around -> we should only keep AESTiny128 and AESTiny256.

You can get rid of AESSmall* and friends.

[nextgens]

I've ended up benchmarking this (see PR above) on ESP32... the specific implementation does not make much difference for our usecase. We definitely don't need all of them though ;)

The most we ever encrypt is packet-length:

AES128 (184 bytes): 371 ms for 500 iterations (0.74 ms avg)
AESTiny128 (184 bytes): 361 ms for 500 iterations (0.72 ms avg)
AESSmall128 (184 bytes): 370 ms for 500 iterations (0.74 ms avg)
AES128_ESP (184 bytes): 370 ms for 500 iterations (0.74 ms avg)

AESTiny is bugged and stops encrypting after a bit, I haven't looked into why

[ViezeVingertjes]

Rebased this branch onto the current dev branch and resolved merge conflicts while preserving the PR scope (vendored crypto subset plus ed25519 reentrancy fixes).

Perhaps we can get this one through if one could validate it on a different setup than mine? More space more better.

[weebl2000]

Rebased this branch onto the current dev branch and resolved merge conflicts while preserving the PR scope (vendored crypto subset plus ed25519 reentrancy fixes).

Perhaps we can get this one through if one could validate it on a different setup than mine? More space more better.

Which devices/platforms have you tested it on? I can have a go on devices I have.

[ViezeVingertjes]

Rebased this branch onto the current dev branch and resolved merge conflicts while preserving the PR scope (vendored crypto subset plus ed25519 reentrancy fixes).
Perhaps we can get this one through if one could validate it on a different setup than mine? More space more better.

Which devices/platforms have you tested it on? I can have a go on devices I have.

T-Echo and T-Beam back then, currently runs on my Wismesh Tag.

• Flashed it over my existing firmware which was all fine.
• Erase + flash to make sure nothing odd happens there.

Later imported my own key etc again and now using it normally.
Probably more than needed as it triggers the same code paths, but better safe than sorry.

[ViezeVingertjes]

Added tests, rebased so its back in business, retested on ESP32 / nRF.