search

near / NEPs

The Near Enhancement Proposals repository
https://nomicon.io
215 stars 137 forks source link

Introduce secp256r1 for transaction signing #312

Open ilblackdragon opened 2 years ago

ilblackdragon commented 2 years ago

NEAR can easily support more curves for signing transactions.

Adding secp256r1 would allow to support web signing and mobile signing from secure enclaves.

There are considerations against secp256r1 around potential backdoors, but given this is an option that users opt-in and can switch away from, I would see this as a powerful extension that would allow to improve security of the mobile and web wallets dramatically.

abacabadabacaba commented 2 years ago

I am against adding more curves. Our code base is already complex enough. Web signing is already possible using Ed25519, and the security benefits of signing using secure enclave are limited. If the user's device is compromised, an attacker can sign a transaction that adds their key to the user's account (and neither Web Crypto API nor enclaves are going to prevent that), and similarly the user can replace their key if they suspect compromise.

stefanopepe commented 2 years ago

There were stories about Secp256r1 being "cooked" by government organizations to add backdoors, posing a risk if they leak. With the option to re-key a NEAR account, in my opinion this specific issue can be mitigated. Looking at Bitcoin history, Secp256k1 went under a lot of scrutinies and even received an "unsafe" tag by this old website, nevertheless, I can't see that users dropped Bitcoin because of that.

I don't have elements to support Evgeny's point, the tradeoff here should be between:

When the latter happens, the former will become a technical debt that (if I understand right) can't be removed until the very last account removed that type of curves.

From a product standpoint, offering this feature would be seamless, but removing it very painful

ryancwalsh commented 1 year ago

Is there more discussion about this idea somewhere other than this ticket?

(Coming from https://www.pagoda.co/blog/protocol-roadmap-2023-4-the-next-2-years-of-near which linked to this ticket, I was surprised to see just a few comments. Based on the fact that the Roadmap highlights this feature, it seems like Pagoda ultimately resolved the disagreement above in favor of moving forward with secp256r1. I'm curious to hear the thought process.)