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 k-256 support #81

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

add k-256 support #81

wants to merge 1 commit into from

Conversation

iameli
Copy link

@iameli iameli commented Oct 31, 2024

My PR for this on c2pa-rs was closed because it's not part of the C2PA spec. Fair enough. If there's a better place to propose this change, please let me know.

My original post on the matter on Discord makes the pitch pretty well, I think:

Curious if there are any feelings about adding secp256k1 (aka ES256K aka k256 aka NIST K-256) signatures into the spec. Our use case is supporting Bluesky's AT Protocol, which requires both that and p256 aka secp256r1 aka prime256v1) which is already supported. But it would also be nice to interoperate with hardware wallets and Ethereum-ecosystem crypto tools like Metamask.

[...] an Aquareum node already has an Ethereum wallet keypair and identity associated with it, so signing segments with that same key would be the most straightforward way to implement it. Or as an end user you could validate that a piece of media is actually associated with iameli.eth or @iame.li on the AT Protocol.

It would also facilitate integration with hardware wallets, which I contend are the best personal-use HSMs out there. As a content creator I'd love to sign each video I upload with my ledger that I already have around; it facilitates really strong personal key security.

"Wasn't this going to be handled as part of the CAWG?" I don't think my use case is pertinent to the CAWG spec, though "attestations about crypto wallets" might be broadly within the CAWG's domain. But we're building an app (and OBS plugin) that allows users to broadcast signed livestreams from their devices. That makes us a claim generator, no?

@lrosenthol
Copy link
Contributor

@iameli Thanks for reaching out with this proposal. I will bring it to the team for discussion and report back!

@lrosenthol lrosenthol self-assigned this Oct 31, 2024
@lrosenthol lrosenthol added the enhancement New feature or request label Oct 31, 2024
@@ -3497,11 +3497,11 @@ <h4 id="_signature_algorithms"><a class="anchor" href="#_signature_algorithms"><
<div class="ulist">
<ul>
<li>
<p>ECDSA requires elliptic curve keys on the P-256, P-384, or P-521 elliptic curves.</p>
<p>ECDSA requires elliptic curve keys on the P-256, K-256, P-384, or P-521 elliptic curves.</p>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to do a bit of research to refresh my memory, but the typical concern with K-256 is that there are a few scenarios where timing attacks could leak information. As used in crypto-currency implementations, the timing attacks are impractical. Generalized use in C2PA might??? be problematic in some scenarios. Leonard, let me know if you want me to dig up the details or run this by cryptographers I work with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants