oreparaz / xsig Goto Github PK

Today we are encoding ECDSA signatures in ASN.1 DER format. This is pretty much the standard. However, signature size in this format isn't constant. Although signature max size is 72 bytes for P-256, there are valid signatures that encode to shorter byte sequence.

The price we pay for convenience (using a standardized format) is complexity: PopSignature needs to do some minimal ASN.1 parsing. While this seems fine today in the current implementation, in other languages might get trickier. We might want to revisit this and move to a "raw" format: concatenate (r,s) and encode each integer as fixed-size, 0-padded, big-endian byte sequence.

There's also not a strong binding between signature scheme (ECDSA over P-256 w/SHA-256) and public keys; this binding is implicit via MachineType so any change to signature scheme / representation needs a bump in MachineType.

There are great ideas in https://bitcoin.sipa.be/miniscript/ , see if we can borrow some

We could use compressed public keys if we want to save some space in the xpublickey. (Today xpublickey scripts are pretty long.)

Support for compressed pubkeys in different libraries isn't stellar, so this probably has low priority.

• For golang we can just use https://pkg.go.dev/crypto/elliptic#UnmarshalCompressed
• In C we'd need to do close this first: oreparaz/p256#13

we can do poor man's "model checking" by plugging a fuzzer under the following constraints:

• fix a small, concretexpublickey
• stub out all the crypto

and let the fuzzer try to find a bad input that shouldn't make verification pass.

add a magic+version header to every serialized data. related to, but not exactly the same as, #23 .

The security argument today is very hand-wavy, and desperately needs some more 👀. Ideally have something semi-formal.

We probably want a crude mechanism to assert the xpublickey script is well formed (or at least, it hasn't been blatantly corrupted). Potential ideas:

• add a short prefix to every xpublickey
• add a short integrity check value (CRC or truncated hash) to make sure the xpublickey is valid.

I'm a bit torn to include this kind of code and wondering if it should live elsewhere, but the failure mode is so catastrophic that I'm inclined for xsig to do some minimal sanity check on xpublickey.

Some questions:

• what fields should the certificate consist of?

related to #21, probably would be good to introduce some operations to read/write some state to store:

• anti-replay counters
• generation/epoch counters
• (maybe) hash of some state

We should have a clear, concrete use case before implementing a generic interface (that might be overkill). Priority should be to get it as simple as possible to make analysis easy.

Some primitive to provide access to NVRAM in some HSMs.

Design decisions:

• absolute time?
• what time synchronization guarantees we have at verification time?

Probably best to push those decisions to the concrete implementation, and just write support for this opcode

Once machine001 is stable and we collect enough test vectors, write an embedded C interpreter.

something that allows for example per-device signing. We should probably settle on "long" device ID (say, 128 bits) and then allow for specific implementations to choose the numbering scheme (sequential, random, structured)