Transclude signature spec.

specs/protocol/cryptographic_primitives.md

@@ -5,6 +5,7 @@
   - [Binary Merkle Tree](#binary-merkle-tree)
   - [Binary Merkle Sum Tree](#binary-merkle-sum-tree)
   - [Sparse Merkle Tree](#sparse-merkle-tree)
+- [Public-Key Cryptography](#public-key-cryptography)
 
 ## Hashing
 
@@ -45,3 +46,25 @@ In other words, the root pair is 40 bytes (8 for fee sum, 32 for hash digest).
 ### Sparse Merkle Tree
 
 A specification for the Sparse Merkle Tree is [here](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/data_structures.md#sparse-merkle-tree).
+
+## Public-Key Cryptography
+
+Consensus-critical data is authenticated using [ECDSA](https://www.secg.org/sec1-v2.pdf), with the curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1). A highly-optimized library is available in C (<https://github.com/bitcoin-core/secp256k1>), with wrappers in Go (<https://pkg.go.dev/github.com/ethereum/go-ethereum/crypto/secp256k1>) and Rust (<https://docs.rs/crate/secp256k1>).
+
+Public keys are encoded in uncompressed form, as the concatenation of the `x` and `y` values. No prefix is needed to distinguish between encoding schemes as this is the only encoding supported.
+
+Deterministic signatures ([RFC-6979](https://tools.ietf.org/rfc/rfc6979.txt)) should be used when signing, but this is not enforced at the protocol level as it cannot be.
+
+Signatures are represented as the `r` and `s` (each 32 bytes), and `v` (1-bit) values of the signature. `r` and `s` take on their usual meaning (see: [SEC 1, 4.1.3 Signing Operation](https://www.secg.org/sec1-v2.pdf)), while `v` is used for recovering the public key from a signature more quickly (see: [SEC 1, 4.1.6 Public Key Recovery Operation](https://www.secg.org/sec1-v2.pdf)). Only low-`s` values in signatures are valid (i.e. `s <= secp256k1.n//2`); `s` can be replaced with `-s mod secp256k1.n` during the signing process if it is high. Given this, the first bit of `s` will always be `0`, and can be used to store the 1-bit `v` value.
+
+`v` represents the parity of the `Y` component of the point, `0` for even and `1` for odd. The `X` component of the point is assumed to always be low, since [the possibility of it being high is negligible](https://bitcoin.stackexchange.com/a/38909).
+
+Putting it all together, the encoding for signatures is:
+
+<!-- markdownlint-disable-next-line MD040 -->
+```
+|    32 bytes   ||           32 bytes           |
+[256-bit r value][1-bit v value][255-bit s value]
+```
+
+This encoding scheme is derived from [EIP 2098: Compact Signature Representation](https://eips.ethereum.org/EIPS/eip-2098).

specs/protocol/tx_validity.md

@@ -133,6 +133,8 @@ for input in tx.inputs:
 return True
 ```
 
+Signatures and signature verification are specified [here](./cryptographic_primitives.md#public-key-cryptography).
+
 The transaction hash is computed as defined [here](./identifiers.md#transaction-id).
 
 ## Predicate Verification

specs/vm/opcodes.md

@@ -1563,6 +1563,8 @@ Panic if:
 - `$rC + 32 > VM_MAX_RAM`
 - The memory range `MEM[$rA, 64]` does not pass [ownership check](./main.md#ownership)
 
+Signatures and signature verification are specified [here](../protocol/cryptographic_primitives.md#public-key-cryptography).
+
 If the signature cannot be verified, `MEM[$rA, 64]` is set to `0` and `$err` is set to `1`, otherwise `$err` is cleared.
 
 To get the address from the public key, hash the public key with [SHA-2-256](#sha256-sha-2-256).