Brainstorming & research - extend signature opcodes with P-256 (secp256r1)

#1

Prompted by a Tweet by matt.bit (Nervos network community):

Prediction: over the next 2 years, every blockchain other than Bitcoin and its offspring will fork to include support for secp256r1 Windows 11 is going passwordless. Here's what you'll be using instead. | Mashable

The “passwordless” method mentioned is the “passkey” method, commonly referred to as CTAP/FIDO2:

The two primary technical specifications that work together to enable passkeys are Web Authentication, commonly referred to as WebAuthn, and the Client to Authenticator Protocol (CTAP), commonly referred to as FIDO2.
The two specs together are often referred to as one stack, FIDO2/WebAuthn.

Spec: Specifications - passkeys.dev

The FIDO Client to Authenticator Protocol , often referred to by its acronym CTAP, is responsible for communications with the authenticator over a number of transports including USB, NFC, and Bluetooth. Operating systems, and in some cases apps, utilize this protocol to pass requests from WebAuthn to the appropriate authenticator over its desired transport.

The standard is getting wide industry acceptance and hardware keys are being mass-produced and are widely available: https://www.pcmag.com/picks/the-best-security-keys-for-multi-factor-authentication

Benefits:

  • Possibility of turning any “authkey” device into a Bitcoin Cash hardware wallet

Costs:

  • One-off node upgrade costs + minimal maintenance

There’s already an EIP for this: EIP-7212: Precompiled for secp256r1 Curve Support

How could it be implemented without breaking non-node software?

Recall how pubkeys read by OP_*SIG* opcodes are encoded.
They have a single byte prefix that can be 02, 03, or 04:

Public key formats

Public keys are also presented in different ways, most importantly as either compressed or uncompressed public keys.

As we saw previously, the public key is a point on the elliptic curve consisting of a pair of coordinates (x,y) . It is usually presented with the prefix 04 followed by two 256-bit numbers, one for the x coordinate of the point, the other for the y coordinate. The prefix 04 is used to distinguish uncompressed public keys from compressed public keys that begin with a 02 or a 03 .

– A. M. Antonopoulos, Mastering Bitcoin, chapter 4

We could add another prefix there, to indicate that the pushed public key is associated with another curve, so the VM can switch signature verification to secp256r1.

This same method could later be used to implement a quantum-resistant signature scheme.

1 Like
2021 BCH upgrade items brainstorm
#3
1 Like
#4

As explained on Telegram, this benefit is doubtful. The devil is in the details.

Any generic purpose “authkey” device needs to differentiate between a virus and a wallet accessing the private keys. It is either OS-level protection (sandboxing) or something like what the CPUs from AMD/Intel have, an ‘enclave’ (SGX). They use cryptography, which means that Intel or AMD signs your app and then it can access the data.

This extra step where your app can access it while a virus can not is effectively destroying all the advantages of segregating the private key. Now Intel (and the US government) have access…
Or maybe it avoids signing and just sets it up on the OS level, well in that case it is just sandboxing with extra steps.

The entire point of a hardware wallet is that it is purpose made, has only one function / usecase and access is decided in the real world instead of at some digitial level.
Stealing your coin from a hardware wallet is the same as stealing your physical wallet with physical paper or coin.

That is the point of a hardware wallet. It moves access to a real world & physical question, not some complex scheme that inevitably creates new problems or introduces new trustees.

From the very simple point of view, the OS sandboxing of apps (as is done on all mobile platforms) is going to be enough for 90% of the people. This means that on Flowee Pay a user can set a PIN and without that it won’t let them access the private keys.

People that feel that this isn’t enough, there isn’t really anything in the middle that actually adds a real benefit until the well known concept of a separate hardware device which is by default offline and is used by exactly one application (the wallet).

Notice, btw, that a simple hardware wallet doensn’t really need a lot. Today most wallets are written in javascript and run in a browser environment. That is super amazing overkill and wastes resources like a politician in a fake democrazy.

A super simple wallet can probably run on an esp32, use NFC or bluetooth to pay to a Point of Sale or a phone and with a new designed payment protocol never needs to connect to the Internet.

1 Like