Refactor of key_derivation #52
Conversation
|
Example isn't complete so this won't pass CI yet. |
sbailey-arm
force-pushed
the
add-key-derivation
branch
3 times, most recently
from
04116d1 to
400b1fa
Compare
| @@ -32,7 +32,7 @@ pub enum Inputs<'a> { | |||
| /// Secret, used in the "extract" step. This is typically a key of type `Derive` , or the shared secret | |||
| /// resulting from a key agreement, using `Input::KeyAgreement`. | |||
| /// Must be a key or key agreement input if used with `psa_key_derivation_output_key`. | |||
There was a problem hiding this comment.
Is it worth duplicating these structs to enforce this? So we'd have an operation struct for output_key and one for output_bytes where the output_key struct only allows a key or key agreement for the secret step?
There was a problem hiding this comment.
No, I think that's overkill, as I assume most of the code would have to be duplicated too, right?
There was a problem hiding this comment.
Yes most of it would have to be duplicated.
There was a problem hiding this comment.
I'd say writing a few lines to check the validity is better than duplicating tens/hundreds to make ensure that statically. If we have a regression test for it that should be enough. Do you think the static checking would bring a big benefit?
There was a problem hiding this comment.
Yes, you're probably right. If someone wants to use this on an embedded device, they may end up appreciating the code size savings over enforcing correct parameters.
Do you think the static checking would bring a big benefit?
Not big, no. It's easy enough to just read the documentation! But if there's a cheap enough way of forcing something to be correct, I'd take it (haven't though of a way to enforce this ).
|
mbedTLS doesn't support key output if key agreement is used as the input for the You will receive |
sbailey-arm
force-pushed
the
add-key-derivation
branch
from
400b1fa to
b033906
Compare
|
Added two tests. One that uses a key for input of secret which runs and passes and a second that uses key agreement as input for secret which is ignored as it will not currently pass. |
|
You seem to have added some commits with the original derivation/agreement work |
I've rebased this onto the branch that I added all of the tests to. Plan was to have the other PR merged to main, then this should show the changes to key derivation. |
sbailey-arm
force-pushed
the
add-key-derivation
branch
from
b033906 to
1415914
Compare
Signed-off-by: Samuel Bailey <samuel.bailey@arm.com>
sbailey-arm
force-pushed
the
add-key-derivation
branch
from
1415914 to
d3a903c
Compare
|
Thanks! Apologies for taking so long to get this in |
Currently, key derivation does not properly support key agreement. This PR is a possible solution.
Signed-off-by: Samuel Bailey samuel.bailey@arm.com