Merged
Conversation
sosthene-nitrokey
force-pushed
the
hpke
branch
from
40ac426 to
f0babe5
Compare
This was referenced Sep 30, 2024
daringer
reviewed
Oct 1, 2024
src/hpke.rs
Outdated
| kem_context, | ||
| &mut shr, | ||
| ) | ||
| .expect("Length of shr is known to be OK"); |
Member
There was a problem hiding this comment.
replace expect with error! + unwrap?
Collaborator
Author
There was a problem hiding this comment.
Is it relevant? it's not used in the real firmware since only the SE050 is used.
Member
There was a problem hiding this comment.
It’s not necessary, but if we would ever end up using the implementation e. g. for the Passkey, we will probably not remember to fix this. On the other hand, maybe the expect optimization will have improved by then. ;)
sosthene-nitrokey
force-pushed
the
hpke
branch
from
105f2f9 to
c31b9ca
Compare
robin-nitrokey
approved these changes
Oct 9, 2024
This will be useful for PIV encryption, working together with trussed-dev/trussed-auth#41 This implements the standard HPKE from [RFC 9180](https://www.rfc-editor.org/rfc/rfc9180.html). This uses a custom implmentation instead of the `hpke` crate because this crate seals the trait to implement custom ciphers, and we want to use `ChaCha8` and not `ChaCha20`. The implementation is tested against the RFC test vectors for `ChaCha20`, and is made generic so that the same code can be used for `ChaCha8` in the backend. For ChaCha8Poly1305 AEAD ID, I used a custom `0xFFFE`, which is probably unused. I need to look if there is somewhere someone already using ChaCha8Poly1305 for HPKE and if there is a specified ID.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This will be useful for PIV encryption, working together with trussed-dev/trussed-auth#41
This implements the standard HPKE from RFC 9180. This uses a custom implmentation instead of the
hpkecrate because this crate seals the trait to implement custom ciphers, and we want to useChaCha8and notChaCha20.The implementation is tested against the RFC test vectors for
ChaCha20, and is made generic so that the same code can be used forChaCha8in the backend.For ChaCha8Poly1305 AEAD ID, I used a custom
0xFFFE, which is probably unused. I need to look if there is somewhere someone already using ChaCha8Poly1305 for HPKE and if there is a specified ID.