Disabling default mechanisms

[arturkow2000]

Hi, Trussed feature flags seem to be broken - disabling unused mechanisms causes build to fail in a hard-to-fix way.

error[E0433]: failed to resolve: use of undeclared crate or module `des`
  --> external/trussed/src/mechanisms/tdes.rs:10:5
   |
10 | use des::cipher::{BlockDecrypt, BlockEncrypt, NewBlockCipher};
   |     ^^^ use of undeclared crate or module `des`
   |
help: there is a crate or module with a similar name
   |
10 | use aes::cipher::{BlockDecrypt, BlockEncrypt, NewBlockCipher};
   |     ~~~

error[E0433]: failed to resolve: use of undeclared crate or module `sha1`
  --> external/trussed/src/mechanisms/totp.rs:22:27
   |
22 |     let mut hmac = Hmac::<sha1::Sha1>::new_from_slice(key).unwrap();
   |                           ^^^^ use of undeclared crate or module `sha1`
   |
help: there is a crate or module with a similar name
   |
22 |     let mut hmac = Hmac::<sha2::Sha1>::new_from_slice(key).unwrap();
   |                           ~~~~

error[E0405]: cannot find trait `Derive` in this scope
   --> external/trussed/src/mechanisms/x255.rs:189:6
    |
189 | impl Derive for super::X255 {}
    |      ^^^^^^ not found in this scope

Without that, Trussed pulls a massive amount of dependencies that are not needed for our project, and cutting them off could save us some kB's.

[nickray]

Hi,

yes due to lack of tasting this is highly probable.

For perspective, the long-term plan is to have some kind of "builder" environment, that starts from a specification:

• which Trussed apps to use
• board / runtime / interface (USB, NFC, ...) data
• backend implementations for cryptographic routines (Cortex-M4 software, cryptographic coprocessors, external devices such as secure elements)

And would then derive (from the app requirements) what cryptography is needed, which implementation to use, and build a firmware bundle out of this.

The idea is definitely that the framework is minimalist after compilation, with the idea that firmware "bundles" of Trussed, the apps and the entire runtime are updated atomically (code update, data untouched).

A little more specifically, in the current state of Trussed, one should distinguish between "core" cryptographic algorithms (such as SHA256 which is used internally as baseline hash, or ChaCha8Poly1305 which is used as baseline AEAD), "nearly core" algorithms (for Trussed device identity, some kind of signing key and some kind of key agreement key is needed; right now this is either P256 for both, or Ed255/X255 - in principle RSA could be used too), and true "fluff" (like SHA-1 which is pulled in here only for TOTP, which shouldn't even be a "mechanism").

Short term, some kind of testing using e.g. cargo-hack with its --feature-powerset might be a pragmatic solution.

Thoughts?