Collect prior art

[chrysn]

Relevant components we draw inspiration from:

• ARM's PSA API does similar things, but as an idiomatic C rather than an idiomatic Rust API.
  • libcose is similar; it also provides more high-level functions, and has a good selection of build-time pluggable backends (mainly concrete crypto implementations)
• The RustCrypto traits provide idiomatic Rust APIs, but provide a single type for a single implementation of an algorithm. embedded-cal will strive to use that existing infrastructure both for back-ends (ideally, it should be easy to glue together any number of RustCrypto traits into a single embedded-cal instance) and on the user level (so that for example once an algorithm is negotiated and a key established with a peer through some protocol, the resulting key material can be used through the traits again).
• embedded-hal / -nal are trait families that inspired the over-all design of embedded-cal: Just like a morse code emitting application should work on any embedded Rust platform that can provide a GPIO and a timer, efficient secure network communication should work on any embedded device that has a suitable hardware accelerator.
• Potential users so far provide bespoke intefaces:
  • Lakers' crypto trait is what this project is evolving out from
  • libOSCORE's native cryptography API in turn influenced Lakers' crypto trait.

Large cryptographic libraries in a sense also fall in this category, because they often gather multiple algorithms internally.

[chrysn]

PSA has gained the capability to split some work among drivers; this is similar to our composability.

[chrysn]

libcrux is also a relevant implementation; @jschneider-bensch can provide details.

[chrysn]

The x25519/dalek crates have explicit API distinguishing serializable from unserializable keys: https://docs.rs/x25519-dalek/latest/x25519_dalek/

Wasn't planned, but won't hurt to consider. To some extent we will have to encode policy around whether or not a generated key may or may not be serialized anyway: Otherwise we can't tell a hardware module whether or not serializing the key without an envelope will be permitted.

[chrysn]

Running in a browser is maybe not the core goal, but it is a popular platform for emulating embedded devices, and having more exotic platforms helps anticipate things that the next hardware platform may do, so: the SubtleCrypto web API is a candidate provider, and thus a source of API inspiration.