Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for C lib cryptographic primitives #4504

Open
AngainorDev opened this issue Mar 27, 2021 · 3 comments
Open

Request for C lib cryptographic primitives #4504

AngainorDev opened this issue Mar 27, 2021 · 3 comments

Comments

@AngainorDev
Copy link

CP currently has hashlib based upon frozen code, providing sha1 and sha256 for instance.
aesio, c lib based, but not included by default in the Pico port.

SHA hash functions are widely used primitives you need for all sorts of things.
I needed them for TOTP code generation (hmac with sha1) for instance.
The pure python code works and is compliant, but takes time (0.2 sec per hmac on the pico)

sha1 and sha256 can be implemented with a small c code and should not take much flash space.
Likely less (space and ram) than doing it on Python.

Moreover, these hashes are used as part of other algorithms.
HMAC for instance, used for message digests ,signatures, but also PKBDF.

The PKBDF2 case is interesting: from a password and salt, using HMAC as a PRNG, you generate a cryptographic key that is supposed to be hard to brute force. In order for it to be secure, you chain as many HMAC as you can afford, like 10 000 or more.
HMAC and SHA speed there is more than important to optimize.

I have a working project where I need bot HMAC and PKBDF2, and that is likely to be a generic use case.
https://github.com/AngainorDev/Picoth

You often need to store private info onto a CP board. The USB drive makes it easy to edit the code, as well as the config.
However that private info is then clearly readable by anyone plugging the device on its computer.
If you use a simple encoding scheme, like a pin code, it's easy to brute force if you get the file.

PKBDF algos makes brute force harder. That would not make the device fully secure (using an extra atecc chip there would make sense) but that would make it significantly harder in practice.

Some modern algos for key extension are not fit for the pico, because they would also require more ram than reasonable.
I tried scrypt for instance, using more hash primitives and ram, and the pico can't stand it with reasonable values.

So, "older" algos like PKBDF2 with sha256 HMAC, that are not ram hungry could still fit, if they were running on C code instead of pure python. They are also small enough the extra code can be tuned for MP boards, and avoid shipping heavy libs.

What I'd like to have as part of regular CP:

  • SHA1 (for OTP codes)
  • SHA256 (for anything)
  • HMAC with SHA1 or 256
  • PKBDF2 with SHA256

To me, these are the most common crypto primitives that many programs could benefit.

@ladyada
Copy link
Member

ladyada commented Mar 27, 2021

we'll review any PR we get, we recommend starting with one function to start :)

@tannewt tannewt added this to the Long term milestone Mar 29, 2021
@tannewt
Copy link
Member

tannewt commented Mar 29, 2021

It'd be great to get more crypto APIs made available. Some chips actually have hardware acceleration as well. The aesio PR has lots of really good API discussion: #2823 (Basically Python's cryptography library is too monolithic to copy.)

@applecuckoo
Copy link

Most of the 'stable' ports have some sort of hardware accelerated cryptography that implements one of these primatives:

  • The SAMD51 has the Integrity Check Monitor for SHA1, SHA224 and SHA256. The SAMD21 doesn't have any of this.
  • The ESP32-S2 has a SHA Accelerator and an HMAC Accelerator
  • The nRF52 has ARM's TrustZone CryptoCell 310 which has SHA and HMAC acceleration
  • And the STMF415xx/7xx has SHA1 and HMAC acceleration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants