What does ecdsa.SignASN1 take as its input, and how is the signature it returns encoded?

## The two functions ```go func SignASN1(rand io.Reader, priv *PrivateKey, hash []byte) ([]byte, error) func VerifyASN1(pub *PublicKey, hash, sig []byte) bool ``` They are the pair you should reach for in `crypto/ecdsa`. Everything interesting about them is in the two byte slices. ## The input is a digest, and you compute it ECDSA is defined over a number derived from a hash of the message; the Go API does not hide that. `hash` is the digest, and choosing it is your job: ```go sum := sha256.Sum256(manifest) sig, err := ecdsa.SignASN1(rand.Reader, priv, sum[:]) ``` `sha256.Sum256` returns a `[32]byte` array, so `sum[:]` slices it. Two failure modes follow directly. Passing the whole message where a digest is expected "works" — the function accepts any byte slice — and produces a signature that nothing else will ever verify, because every other implementation hashes first. And hashing twice, once in your helper and once again in a wrapper, produces the same silent interop failure. If the digest is longer than the curve's order, ECDSA uses its leftmost bits, so a SHA-512 digest with P-256 is legal but only the first bits participate; matching the hash size to the curve (SHA-256 with P-256, SHA-384 with P-384) is the convention. Contrast this with Ed25519, whose `ed25519.Sign` takes the message because the scheme hashes internally. The two APIs look similar and want opposite inputs. ## The randomness argument is not decorative ECDSA needs a fresh secret value per signature. If that value repeats across two signatures made with the same key, the private key can be recovered from the pair; if it is merely biased, enough signatures still leak it. That is why `SignASN1` takes an `io.Reader` at all, and why the only correct production argument is `crypto/rand.Reader`. A fixed or seeded reader belongs in nothing but a test that must reproduce an exact byte string. Ed25519 has no such parameter because it derives its per-signature value deterministically from the key and the message. ## The output is DER, so the length varies An ECDSA signature is mathematically a pair of integers, r and s. There are two common ways to put that pair on a wire: 1. **ASN.1 DER** — a SEQUENCE of two INTEGERs, each minimally encoded and each carrying a leading zero byte when its top bit is set. This is what `SignASN1` emits. On P-256 the result is usually 70–72 bytes and occasionally shorter, because r or s can happen to have leading zero bytes. 2. **Fixed-width r‖s** — each integer left-padded with zeros to the curve's byte length and concatenated, giving exactly 64 bytes on P-256. This is what JOSE/JWS ES256 and the browser WebCrypto API use. Go's `crypto/ecdsa` speaks only the first. When a counterparty rejects every signature you produce and the digests match, this encoding mismatch is the usual cause. Converting is mechanical: decode the DER with `encoding/asn1` into a struct of two `*big.Int` fields, then write each one as a fixed-width big-endian slice. What you must never do is chop bytes off the front of the DER blob — the tags, lengths and any leading zero bytes are not padding. ## What about ecdsa.Sign? `ecdsa.Sign(rand, priv, hash) (r, s *big.Int, err error)` is the older, lower-level form: it hands you the raw integers and leaves the encoding entirely to you. That is how mismatched wire formats get invented in the first place, so prefer `SignASN1` unless you specifically need a non-DER layout, in which case the `big.Int` form saves you a decode step. The matching `ecdsa.Verify` takes r and s as `*big.Int` values, not bytes. ## Through the interface `*ecdsa.PrivateKey` also has a `Sign(rand, digest, opts)` method, so it satisfies `crypto.Signer`, and that method returns the same ASN.1 DER encoding. Its `opts` must report a real hash function — `crypto.SHA256` for a SHA-256 digest — and the digest length is expected to match. `priv.PublicKey` is an embedded field, so `&priv.PublicKey` is what you hand to `VerifyASN1`.