Skip to content
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

Merged
merged 45 commits into from
Nov 20, 2024
Merged

add support for ecdsa signatures #108

merged 45 commits into from
Nov 20, 2024

Conversation

Geal
Copy link
Contributor

@Geal Geal commented Oct 11, 2022

@Geal Geal changed the base branch from main to v5 May 23, 2024 07:38
Geal added 8 commits May 23, 2024 09:39
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
@Geal Geal marked this pull request as ready for review May 23, 2024 12:40
Copy link

codspeed-hq bot commented May 26, 2024

CodSpeed Performance Report

Merging #108 will not alter performance

Comparing fipscuit (543d0f1) with v5 (4556320)

Summary

✅ 12 untouched benchmarks

Copy link

codecov bot commented May 26, 2024

Codecov Report

Attention: Patch coverage is 62.80193% with 154 lines in your changes missing coverage. Please review.

Please upload report for BASE (v5@4556320). Learn more about missing BASE report.
Report is 1 commits behind head on v5.

Files with missing lines Patch % Lines
biscuit-auth/src/crypto/ed25519.rs 54.32% 37 Missing ⚠️
biscuit-auth/src/crypto/p256.rs 55.26% 34 Missing ⚠️
biscuit-auth/src/crypto/mod.rs 72.97% 30 Missing ⚠️
biscuit-auth/src/token/builder.rs 32.00% 17 Missing ⚠️
biscuit-capi/src/lib.rs 0.00% 14 Missing ⚠️
biscuit-auth/src/token/unverified.rs 0.00% 11 Missing ⚠️
biscuit-parser/src/builder.rs 0.00% 4 Missing ⚠️
biscuit-auth/src/token/mod.rs 76.92% 3 Missing ⚠️
biscuit-auth/examples/third_party.rs 0.00% 2 Missing ⚠️
biscuit-auth/examples/testcases.rs 98.33% 1 Missing ⚠️
... and 1 more
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.
📢 Have feedback on the report? Share it here.


🚨 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);
Copy link
Collaborator

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)

biscuit-auth/src/crypto/mod.rs Outdated Show resolved Hide resolved
biscuit-auth/src/datalog/symbol.rs Outdated Show resolved Hide resolved
biscuit-auth/src/token/builder.rs Outdated Show resolved Hide resolved
biscuit-auth/src/token/builder.rs Outdated Show resolved Hide resolved
@@ -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> {
Copy link
Collaborator

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

Copy link
Contributor Author

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?

Copy link
Collaborator

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

biscuit-auth/src/token/unverified.rs Outdated Show resolved Hide resolved
biscuit-auth/src/token/mod.rs Outdated Show resolved Hide resolved
biscuit-auth/src/capi.rs Outdated Show resolved Hide resolved
@@ -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"] }
Copy link
Collaborator

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?

Copy link
Contributor Author

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?

Copy link
Collaborator

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

Copy link
Contributor Author

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"] }
Copy link
Collaborator

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> {
Copy link
Collaborator

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

@Geal Geal merged commit d956655 into v5 Nov 20, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants