-
Notifications
You must be signed in to change notification settings - Fork 32
Add RSA mechanisms and key serialization format #89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -568,13 +568,17 @@ pub enum Mechanism { | |
| X255, | ||
| /// Used to serialize the output of a diffie-hellman | ||
| SharedSecret, | ||
| Rsa2048Pkcs1v15, | ||
| Rsa3072Pkcs1v15, | ||
| Rsa4096Pkcs1v15, | ||
| } | ||
|
|
||
| pub type LongData = Bytes<MAX_LONG_DATA_LENGTH>; | ||
| pub type MediumData = Bytes<MAX_MEDIUM_DATA_LENGTH>; | ||
| pub type ShortData = Bytes<MAX_SHORT_DATA_LENGTH>; | ||
|
|
||
| pub type Message = Bytes<MAX_MESSAGE_LENGTH>; | ||
| pub type SerializedKey = Bytes<MAX_KEY_MATERIAL_LENGTH>; | ||
|
|
||
| #[derive(Copy, Clone, Eq, PartialEq, Debug, Serialize, Deserialize)] | ||
| pub enum KeySerialization { | ||
|
|
@@ -584,6 +588,12 @@ pub enum KeySerialization { | |
| EcdhEsHkdf256, | ||
| Raw, | ||
| Sec1, | ||
| /// Used by backends implementing RSA. | ||
| /// | ||
| /// Since RSA keys have multiple parts, and that the [`SerializeKey`](crate::api::Reply::SerializeKey) and | ||
| /// [`UnsafeInjectKey`](crate::api::Request::UnsafeInjectKey) have only transfer one byte array, the RSA key is serialized with postcard | ||
| RsaParts, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about calling this
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I want to keep it generic and let the backend decide on the actual data format (for now at least)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The serialization format doesn't affect how they're stored. I don't want to reuse The "Parts" is in contrast to the PKCS format. The PKCS format is defined, but the "Parts" formats contains each element of a public key separately. The "part" name is more representative than "Internal" or "Private". "Serde" feels out of place. The use of postcard and serde is more of a workaround that the actual goal of the API. If you look at the traits in fn unsafe_inject_rsa4096<'c>(
&'c mut self,
key_parts: RsaImportFormat,
attributes: StorageAttributes,
) -> ClientResult<'c, reply::UnsafeInjectKey, Self>;
fn deserialize_rsa4096_public_key<'c>(
&'c mut self,
key_parts: RsaPublicParts,
attributes: StorageAttributes,
) -> ClientResult<'c, reply::DeserializeKey, Self>;Ideally I would even merge the Maybe we should have mechanism extensions? That would mean more generics though.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I understand. My point is just that
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or what about
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I disagree. Whatever we do we will need a way to access specific parts of RSA keys. Both PIV and OpenPGP need that (OpenPGP needs it for both public and private keys, PIV at least for public keys).
I'm not a fan of loosing readability for more flexibility when there are no obvious benefits to it. Do you know of any other algorithm that would use this? |
||
| Pkcs8Der, | ||
| } | ||
|
|
||
| pub type Signature = Bytes<MAX_SIGNATURE_LENGTH>; | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.