-
Notifications
You must be signed in to change notification settings - Fork 1
Description
In this project, we will build an abstraction layer (as a Rust trait or family of traits) that provides the best of formally verified implementations and hardware cryptography to Rust programs. The actual operations will be performed through established Rust crypto traits; this is about representing a platform's provided operations. (Comparing to embedded-hal and Ariel OS, the existing traits are what embedded-hal is, whereas this project abstracts over what stm32-hal and nrf52-hal do for setting up GPIO pins etc).
In this issue, we collect wishlists of what this should do – well aware that part of all this will also be setting scope, but that doesn't need to stop us from wishes coming in.
My personal baseline, informed from the project setup, is:
- no_std [edit: added; can't believe I missed it, seemed so obvious but thanks Mališa for pointing it out]
- Provide cryptographic primitives:
- AEAD encryption/decryption
- possibly composed of hardware encryption primitives combined with software extension, eg. combining hardware AES with software CCM
- Ideally streaming AAD
- Ideally even streaming data (eg. from a scatter-gather buffer), but that might be unrealistic
- Do we need to split in-place/out-of-place operations? (My focus is on in-place)
- ECDSA
- Ideally with streaming AAD
- ECDH
- Cryptographic hashes (definitely streaming)
- HKDF (not sure if extract/expand split is meaningful)
- Possibly HPKE?
- Possibly post-quantum mechanisms?
- Maybe plain symmetric encryption (possibly expressed through COSE's deprecated algorithms mechanism, possibly using an extra mechanism; should have a unified mechanism for group OSCORE)
- AEAD encryption/decryption
- Don't impose size limits that the user can not easily tune.
- Where possible, avoid that the user needs to provide a buffer (through generics or already allocated) for intermediate operations. (👀 ECDSA AAD)
- Query algorithms / curves by COSE number, ideally in a const way.
- Provide associated types that users of the library can use to carry around any intermediate results they need (such that they don't need to know the supported algorithms and thus sizes explicitly).
- Allow backends to only give keys out by handle
- Actually hard decisions:
- Handle exclusive access? This could be a conflict-heavy point, as users expect that backends to work on a &self (or even a Copy Self, which indeed many backends can provide), whereas some backends need a &mut and can only provide that if they manually and statefully lock themselves, and then enqueue operations (on the stack?) or fail them on reentrancy.
- Some might want to use eg. signature operations in an async way.
- Maybe out of scope: Provide high-level COSE operations (COSE_Encrypt etc)
- Be usable as a backend for
- EDHOC (lakers)
- OSCORE (liboscore)
- SUIT (Ariel OS)
- Anything libcose is used for (especially if not listed above)