-
Notifications
You must be signed in to change notification settings - Fork 30
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
add support for ecdsa signatures #108
Conversation
Geal
commented
Oct 11, 2022
•
edited
Loading
edited
- Support for ECDSA signatures on curve secp256r1 biscuit#165
Since we can now have multiple algorithms, we cannot know during deserialization the right size of a signature, so that check is now removed. A signature with an invalid size will generate an error later during verification anyway
CodSpeed Performance ReportMerging #108 will not alter performanceComparing Summary
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v5 #108 +/- ##
=====================================
Coverage ? 65.16%
=====================================
Files ? 27
Lines ? 6972
Branches ? 0
=====================================
Hits ? 4543
Misses ? 2429
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
@@ -11,7 +11,7 @@ use rand::rngs::OsRng; | |||
|
|||
fn create_block_1(b: &mut Bencher) { | |||
let mut rng = OsRng; | |||
let root = KeyPair::new_with_rng(&mut rng); | |||
let root = KeyPair::new_with_rng(Algorithm::Ed25519, &mut rng); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it could be done in another PR, but adding benches for other signature algorithms would be nice (eg making the bench suite parametric on the algorithm, and running it for each supported algorithm)
@@ -99,7 +101,8 @@ impl UnverifiedBiscuit { | |||
/// since the public key is integrated into the token, the keypair can be | |||
/// discarded right after calling this function | |||
pub fn append(&self, block_builder: BlockBuilder) -> Result<Self, error::Token> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i assume the primary use-case for ECDSA is for the authority block and external signatures, and that we’re ok using ed25519 for attenuation blocks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if people are using ECDSA somewhere, it is likely that they would use it everywhere. Would you prefer that the algorithm stays the same over the entire token?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i assume the need for using ecdsa is mostly for sensitive keys that need hardware support (eg HSM / smart card, etc). Block keys are not as sensitive as they’re single use, so i guess defaulting to ed25519 is ok here. Also, block keys need the secret key to be accessed directly and stored in the token, so that would not work with a HSM
@@ -50,6 +50,10 @@ biscuit-parser = { version = "0.1.2", path = "../biscuit-parser" } | |||
biscuit-quote = { version = "0.2.2", optional = true, path = "../biscuit-quote" } | |||
chrono = { version = "0.4.26", optional = true, default-features = false, features = ["serde"] } | |||
serde_json = "1.0.117" | |||
ecdsa = { version = "0.16.9", features = ["signing", "verifying", "pem", "alloc", "pkcs8", "serde"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we feature-gate ecdsa support?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can, but what would it bring? Reducing the number of dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that’s what we’ve done for pem/der support iirc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the API already exposes the algorithm in key creation everywhere, feature gating it after that would make it a little bit more annoying
@@ -50,6 +50,10 @@ biscuit-parser = { version = "0.1.2", path = "../biscuit-parser" } | |||
biscuit-quote = { version = "0.2.2", optional = true, path = "../biscuit-quote" } | |||
chrono = { version = "0.4.26", optional = true, default-features = false, features = ["serde"] } | |||
serde_json = "1.0.117" | |||
ecdsa = { version = "0.16.9", features = ["signing", "verifying", "pem", "alloc", "pkcs8", "serde"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that’s what we’ve done for pem/der support iirc
@@ -99,7 +101,8 @@ impl UnverifiedBiscuit { | |||
/// since the public key is integrated into the token, the keypair can be | |||
/// discarded right after calling this function | |||
pub fn append(&self, block_builder: BlockBuilder) -> Result<Self, error::Token> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i assume the need for using ecdsa is mostly for sensitive keys that need hardware support (eg HSM / smart card, etc). Block keys are not as sensitive as they’re single use, so i guess defaulting to ed25519 is ok here. Also, block keys need the secret key to be accessed directly and stored in the token, so that would not work with a HSM