Post-Quantum Cryptography #200
Conversation
| // Keys are often stored in serialized format (e.g. PKCS#8 used by the RSA backend), | ||
| // so material max length must be serialized max length. | ||
| pub type Material = Vec<u8, { MAX_SERIALIZED_KEY_LENGTH }>; |
There was a problem hiding this comment.
This should not be changed, max KEY_MATERIAL_LENGTH should reflect the proper length for key material data.
There was a problem hiding this comment.
There seems to be an issue with the trussed-rsa-backend and fido-authenticator where it's using the wrong sizes for byte arrays. If you clone this repo, patch to use the local copy, and revert this (and the other reference) back to MAX_KEY_MATERIAL_LENGTH, you'll get all sorts of build errors when building nitrokey-3-firmware/runners/usbip.
cargo build --features provisioner
error[E0308]: mismatched types
--> /mnt/c/Users/KyleKotowick/Documents/GitHub/sandbox-quantum/fido-authenticator/src/ctap1.rs:150:13
|
145 | Ok(register::Response::new(
| ----------------------- arguments to this function are incorrect
...
150 | cert,
| ^^^^ expected `1024`, found `2258`
|
= note: expected struct `heapless_bytes::Bytes<1024>`
found struct `heapless_bytes::Bytes<2258>`
cargo build --features provisioner,backend-mldsa44,backend-mldsa65,backend-mldsa87
error[E0308]: `?` operator has incompatible types
--> /mnt/c/Users/KyleKotowick/Documents/GitHub/sandbox-quantum/trussed-rsa-backend/src/crypto_traits.rs:74:29
|
74 | serialized_key: key_parts.serialize().map_err(|_err| {
| _____________________________^
75 | | error!("Failed to serialize key parts: {:?}", _err);
76 | | ClientError::DataTooLarge
77 | | })?,
| |_______________^ expected `7523`, found `7519`
|
= note: `?` operator cannot convert from `heapless_bytes::Bytes<7519>` to `heapless_bytes::Bytes<7523>`
= note: expected struct `heapless_bytes::Bytes<7523>`
found struct `heapless_bytes::Bytes<7519>`
error[E0308]: mismatched types
--> /mnt/c/Users/KyleKotowick/Documents/GitHub/sandbox-quantum/trussed-rsa-backend/src/lib.rs:215:30
|
215 | Ok(reply::SerializeKey { serialized_key })
| ^^^^^^^^^^^^^^ expected `7523`, found `7519`
|
= note: expected struct `heapless_bytes::Bytes<7523>`
found struct `heapless_bytes::Bytes<7519>`
Among others. I've tried to dig into this, but given that the mismatch for the last example is between 7519 bytes and 7523 bytes, which correspond to the MAX_KEY_MATERIAL_LENGTH and MAX_SERIALIZED_KEY_LENGTH sizes respectively, there's something fishy going on. If you could try it, you might have more luck identifying where the issue is.
There was a problem hiding this comment.
Yeah, that looks like the issue of using type aliases instead of newtypes, which means that there doesn't need to be explicit conversions between types.
I'm looking into it.
| let location = self.location(secrecy, id).ok_or(Error::NoSuchKey)?; | ||
|
|
||
| let bytes: Bytes<{ MAX_KEY_MATERIAL_LENGTH }> = store::read(&self.store, location, &path)?; | ||
| let bytes: Bytes<{ MAX_SERIALIZED_KEY_LENGTH }> = store::read(&self.store, location, &path)?; |
| pub const MAX_FIDO_WRAPPED_KEY_LENGTH: usize = | ||
| if cfg!(feature = "mldsa87") || cfg!(feature = "mldsa65") || cfg!(feature = "mldsa44") { | ||
| MAX_SERIALIZED_KEY_LENGTH + 57 | ||
| } else { | ||
| // Default from before addition of PQC | ||
| 128 | ||
| }; | ||
|
|
There was a problem hiding this comment.
This should be in FIDO itself not in trussed, or at the very least #[doc(hidden)].
| // 30 bytes are added by CBOR serialization of a FullCredential | ||
| // TODO: This was calculated by debugging and finding each location where this variable needed to be larger for one reason or another. | ||
| // Update this to use different consts for each area where this is needed, instead of one const used everywhere. | ||
| pub const MAX_MESSAGE_LENGTH: usize = MAX_FIDO_WRAPPED_KEY_LENGTH + 30 + 2031 + 32 + 37; |
There was a problem hiding this comment.
This is way too large. It needs to be at least feature flag.
The Nitrokey 3 has up to 7 client apps. Due to the interchange, this means statically allocating 7 buffers of size around 2*Message. We are pretty limited in terms of memory, and this, even with the feature flag disabled, will double the size of the interchanges, leading to too much memory usage.
There was a problem hiding this comment.
You can use cargo t -- --ignored to run the test in tests/interchange_size to keep track of how high you bumped the interchange size.
No description provided.