Fix RFC 6979 nonconformance; INVARIANT-34 rewritten, INVARIANT-35 added

RFC 6979 conformance
--------------------
ama_nistp_ecdsa_sign normalised `s` to the low representative
unconditionally, so it failed RFC 6979's own Appendix A.2.5/A.2.6/A.2.7
vectors on every case whose natural `s` came out high — roughly half —
while the header advertised "deterministic per RFC 6979". `r` matched
everywhere, so the nonce derivation was correct and the divergence was
invisible to every test that existed.

It was invisible for a second, worse reason: the "independent" reference
in tests/test_nistp_curves.py normalised too, because it was written
alongside the C code rather than from the specification. Two
implementations that share an assumption do not check each other.

Signing now emits RFC 6979's `s` verbatim. All 18 in-scope vectors from
the RFC are vendored under tests/kat/rfc6979/ and replayed, including the
RFC's printed public keys. _ref_sign takes the policy as a parameter
instead of baking one in.

INVARIANT-34 — low-`s` is a property of the sign/verify pair
------------------------------------------------------------
Normalising on the signer while verifying permissively — what shipped —
prevents nothing: the twin of an AMA signature still verifies under AMA.
It only costs conformance. The pair is the control; either half alone is
a costume.

NIST prime curves now default to neither half; secp256k1 keeps both
(INVARIANT-28 unchanged). New ama_nistp_ecdsa_sign_ex / _sign_raw_ex make
every combination of {deterministic, hedged} x {DER, raw} x {RFC s, low s}
reachable through one entry point, with unknown flag bits rejected. The
previous API made hedged+raw raise purely because a fourth function had
not been written.

INVARIANT-35 — a selector must never resolve weaker than it was asked
---------------------------------------------------------------------
INVARIANT-7 covers availability; nothing covered selection until the
library grew nine selectable levels across three families. A selector that
maps an unrecognised value onto a neighbour produces working code, valid
signatures and successful handshakes at a level nobody chose, and never
surfaces.

tests/test_selector_strictness.py derives its selector list from the
modules rather than a literal, drives each with plausible near-misses
including every other family's valid values, and asserts the C side
returns 0/NULL rather than another set's size.

It found one on its first run: ama_nist_curve_t was 0/1/2, so `0` — what
an uninitialised field holds — meant P-256. Renumbered to 256/384/521,
which also no longer collides with the ML-KEM or ML-DSA selector spaces.

Also
----
NativeBackendUnavailableError is now the single type for "native backend
missing", replacing 36 bare RuntimeError raises. PQCUnavailableError is a
subclass, so every existing except-clause is unaffected; asserted directly
rather than assumed.

ctest 56/56, pytest 2854 passed, Wycheproof 4263/0 failures, all gates green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GtRczQn3XzfaikLDrxJLZZ

Author: claude

CHANGELOG.md

@@ -19,8 +19,69 @@ All notable changes to AMA Cryptography will be documented in this file. The for
 
 ## [Unreleased]
 
+### Fixed
+
+- **`ama_nistp_ecdsa_sign` did not conform to RFC 6979.** The signer normalised
+  `s` to the low representative unconditionally, so it failed RFC 6979's own
+  Appendix A.2.5 / A.2.6 / A.2.7 vectors on every case whose natural `s` came
+  out high — roughly half of them — while the header advertised "deterministic
+  per RFC 6979". `r` matched everywhere, so the nonce derivation was correct and
+  the divergence was invisible to every test that existed.
+
+  It was invisible for a second reason worth recording: the "independent"
+  pure-Python reference in `tests/test_nistp_curves.py` normalised too, because
+  it was written alongside the C code rather than from the specification. Two
+  implementations that share an assumption do not check each other. `_ref_sign`
+  now takes the signing policy as a parameter, and RFC 6979's own 18 in-scope
+  vectors are vendored under `tests/kat/rfc6979/` and replayed on every run —
+  including the RFC's printed public keys — so neither implementation can talk
+  its way out of the specification again.
+
+  Signing now emits RFC 6979's `s` verbatim. Low-`s` is opt-in via
+  `AMA_NISTP_ECDSA_SIGN_LOW_S` / `low_s=True`.
+
+### Changed
+
+- **INVARIANT-34 rewritten around the sign/verify pair.** Low-`s` normalisation
+  and high-`s` rejection are two halves of one control: with a permissive
+  verifier, normalising on the signer prevents nothing (the twin of an AMA
+  signature still verifies under AMA) and costs conformance. The NIST prime
+  curves now default to neither half; secp256k1 keeps both (INVARIANT-28,
+  unchanged). `tests/test_nistp_curves.py::test_low_s_is_a_property_of_the_sign_verify_pair`
+  asserts the four-way truth table directly.
+
+- **New `ama_nistp_ecdsa_sign_ex` / `_sign_raw_ex` with policy flags.** Every
+  combination of {deterministic, hedged} x {DER, raw} x {RFC 6979 `s`, low `s`}
+  is now reachable through one entry point; unknown flag bits are rejected
+  rather than ignored. The previous API made hedged+raw raise purely because a
+  fourth function had not been written.
+
+- **`ama_nist_curve_t` renumbered to 256 / 384 / 521** (was 0 / 1 / 2). A dense
+  index made `0` — the value an uninitialised or forgotten field holds — mean
+  "P-256". Found by the new INVARIANT-35 suite on its first run. The values also
+  no longer collide with `ama_ml_kem_param_set_t` or `ama_ml_dsa_param_set_t`,
+  so a call routed to the wrong family is refused rather than resolved. This is
+  a source-and-ABI change to an API that has not shipped in a release.
+
+- **`NativeBackendUnavailableError`** is now the single type for "the native
+  backend is not present", replacing 36 bare `RuntimeError` raises across
+  `pqc_backends.py`. `PQCUnavailableError` is now a subclass, so every existing
+  `except PQCUnavailableError` and `except RuntimeError` handler is unaffected.
+
 ### Added
 
+- **INVARIANT-35 — a selector must never resolve weaker than it was asked.**
+  INVARIANT-7 governs the availability axis (no backend, no operation); nothing
+  governed the *selection* axis until the library grew nine selectable security
+  levels across three families. A selector that maps an unrecognised value onto
+  a neighbour produces working code, valid signatures and successful handshakes
+  at a level nobody chose, and never surfaces. Enforced by
+  `tests/test_selector_strictness.py` (41 tests), which derives its list of
+  selectors from the modules rather than a hand-written literal, drives each
+  with plausible near-misses including every *other* family's valid values, and
+  asserts the C side returns `0` / `NULL` rather than another set's size.
+
+
 - **NIST prime curves P-256 / P-384 / P-521 — ECDSA and ECDH.** New native
   implementation `src/c/ama_nistp.c` (curve parameters from SP 800-186, ECDSA
   from FIPS 186-5, ECDH from SP 800-56A §5.7.1.2, deterministic nonces from

INVARIANTS.md

@@ -1245,69 +1245,152 @@ parsed block.
 
 ---
 
-## INVARIANT-34 — ECDSA Low-`s` Policy Is Per-Curve and Declared
-
-**Statement.** Every AMA ECDSA signer, on every curve, emits only the low
-representative (`s <= (n-1)/2`). Verification policy is **per curve** and each
-choice is stated in the header, in the tests, and here:
-
-- **secp256k1** rejects a high `s` by default (INVARIANT-28), selectable via
-  `ama_secp256k1_ecdsa_verify_ex(..., AMA_SECP256K1_ECDSA_ALLOW_HIGH_S)`.
-- **P-256 / P-384 / P-521** accept either representative by default, and reject
-  the high twin only under `AMA_NISTP_ECDSA_REQUIRE_LOW_S`.
-
-The checks that cost no interoperability are unconditional on both curves and
-in both modes: minimal DER only, `r` and `s` strictly in `[1, n-1]` rather than
+## INVARIANT-34 — Low-`s` Is a Property of the Sign/Verify Pair
+
+**Statement.** Low-`s` normalisation and high-`s` rejection are **two halves of
+one control**. A curve's default must set both or neither, and any API that
+exposes them must expose both.
+
+- **secp256k1** sets both by default: `ama_secp256k1_ecdsa_sign` emits only the
+  low representative and `ama_secp256k1_ecdsa_verify` rejects the high twin
+  (INVARIANT-28). `AMA_SECP256K1_ECDSA_ALLOW_HIGH_S` relaxes the verifier for
+  third-party X9.62 interop.
+- **P-256 / P-384 / P-521** set neither by default: `ama_nistp_ecdsa_sign`
+  emits RFC 6979's `s` verbatim and `ama_nistp_ecdsa_verify` accepts either
+  representative. `AMA_NISTP_ECDSA_SIGN_LOW_S` and
+  `AMA_NISTP_ECDSA_REQUIRE_LOW_S` turn both halves on together.
+
+The checks that cost no interoperability are unconditional on every curve in
+every mode: minimal DER only, `r` and `s` strictly in `[1, n-1]` rather than
 reduced into range, and public-key coordinates strictly in `[0, p)`.
 
-**Why.** The two curves live in different worlds, and a single global policy is
-wrong for one of them.
-
-secp256k1 signatures are identifiers. A blockchain transaction is addressed by
-its signature bytes, so accepting `(r, n - s)` means one transaction has two
-identities — the malleability class that INVARIANT-26 and INVARIANT-28 exist to
-close. AMA controls the signer in every path where it produces secp256k1
-signatures, so strict is free.
-
-The NIST prime curves exist here for the opposite reason: to verify signatures
-AMA did *not* produce. X9.62, FIPS 186-5, RFC 3279, TLS, X.509, JWS and WebAuthn
-all permit either `s`, and essentially none of their signers normalise. A
-strict-by-default verifier would reject conformant third-party signatures — it
-would not be "more secure", it would be non-interoperable, defeating the entire
-purpose of adding the curves.
-
-The asymmetry is therefore a deliberate decision about *what each curve is for*,
-not an oversight or a weakening. Making it an invariant is what stops a future
-change from "harmonising" the two defaults in either direction without
-re-reading this reasoning.
-
-**Enforcement.** In `src/c/ama_nistp.c`, `nistp_ecdsa_sign_core()` negates a
-high `s` unconditionally before encoding, and `nistp_ecdsa_verify_rs()` rejects
-one only when `AMA_NISTP_ECDSA_REQUIRE_LOW_S` is set. The range and
-canonical-coordinate gates (`nistp_scalar_load`, `nistp_load_point`) and the
-strict DER parser (`nistp_der_parse`) are outside the flag entirely.
-`ama_secp256k1.c` is unchanged.
+**Why.** Normalisation on its own prevents nothing. If the verifier accepts
+both representatives, then given any AMA signature `(r, s)` anyone can emit
+`(r, n - s)` and AMA itself will accept it. The signature is malleable
+regardless of what the signer chose. Normalisation only becomes a security
+property when the verifier refuses the twin — the pair is the control, and
+either half alone is a costume.
+
+This is not hypothetical: it is the defect this invariant was rewritten to fix.
+The first version of the NIST prime-curve support normalised on the signer and
+verified permissively — the one combination with no security benefit — and paid
+for it in conformance. `ama_nistp_ecdsa_sign` advertised itself as
+"deterministic per RFC 6979" while failing RFC 6979's own Appendix A.2.5 /
+A.2.6 / A.2.7 vectors on every case whose natural `s` came out high, roughly
+half of them. `r` matched everywhere, so the nonce derivation was right and the
+divergence was invisible to every test that existed.
+
+It was invisible for a second, worse reason. The "independent" pure-Python
+reference in `tests/test_nistp_curves.py` normalised too, because it was
+written alongside the C code rather than from the specification. Two
+implementations that share an assumption do not check each other. **A reference
+must be derived from the specification only, never from the implementation it
+checks** — that rule is the durable lesson here, and it is why `_ref_sign` now
+takes the policy as a parameter instead of baking one in.
+
+The per-curve defaults then follow from what each curve is *for*. secp256k1
+signatures are identifiers — a blockchain transaction is addressed by its
+signature bytes, so two valid encodings means two identities, and AMA controls
+both ends, so strict is free. The NIST prime curves exist here to interoperate
+with signers AMA did not write: X9.62, FIPS 186-5, RFC 3279, TLS, X.509, JWS
+and WebAuthn all permit either `s` and essentially none of their signers
+normalise, so a strict default would reject conformant signatures — not "more
+secure", just non-interoperable, defeating the reason the curves were added.
+
+**Enforcement.** In `src/c/ama_nistp.c`, `nistp_ecdsa_sign_core()` takes
+`low_s` as a parameter and `nistp_sign_dispatch()` derives it from
+`AMA_NISTP_ECDSA_SIGN_LOW_S`; unknown flag bits are rejected rather than
+ignored. `nistp_ecdsa_verify_rs()` rejects a high `s` only under
+`AMA_NISTP_ECDSA_REQUIRE_LOW_S`. The range, canonical-coordinate and strict-DER
+gates sit outside both flags. `src/c/ama_secp256k1.c` is unchanged.
 
 **Wycheproof consequence, declared.** The secp256k1 divergence policy
-`ecdsa/high-s-rejected` in `wycheproof_vectors/run_wycheproof.py` claims exactly
-72 vectors and is scoped to `ecdsa_secp256k1_sha256_test.json` by filename. The
-three NIST prime-curve suites — 1530 vectors — need **no** divergence policy at
-all, and pass with zero exceptions. That asymmetry in the gate output is the
-visible evidence for this invariant: if someone made the NIST default strict, a
-new uncounted divergence bucket would appear and the gate would go red.
-
-**Timing posture.** Signing is constant time with respect to the private key and
-the RFC 6979 nonce on both curves. Verification is variable time by design on
-both — every input is public.
-
-**Verification.** `tests/test_nistp_curves.py::
-test_high_s_twin_accepted_by_default_rejected_when_strict` asserts *both*
-directions on all three prime curves: the twin verifies by default and does not
-verify under `require_low_s`. `test_signing_always_emits_low_s` asserts the
-signer half over freshly generated keys.
+`ecdsa/high-s-rejected` claims exactly 72 vectors and is scoped by filename.
+The three NIST prime-curve suites — 1530 vectors — need no divergence policy at
+all and pass with zero exceptions. That asymmetry in the gate output is the
+visible evidence for this invariant: making the NIST default strict would
+create a new uncounted divergence bucket and turn the gate red.
+
+**Timing posture.** Signing is constant time with respect to the private key
+and the RFC 6979 nonce on both curves; the normalisation is a conditional
+negation of a value that is about to be published. Verification is variable
+time by design on both — every input is public.
+
+**Verification.**
+`tests/test_nistp_curves.py::test_rfc6979_published_vectors` replays all 18
+in-scope vectors from RFC 6979 Appendix A.2.5/A.2.6/A.2.7 (vendored under
+`tests/kat/rfc6979/`), asserting the RFC's own public key and both signature
+components, and fails if the corpus ever stops containing a high-`s` case —
+without one it could no longer detect silent normalisation.
+`test_rfc6979_vectors_reject_low_s_normalisation` pins the opposite direction,
+so the trade-off is a fact in CI rather than a claim in a docstring.
+`test_low_s_is_opt_in_and_default_is_rfc6979_verbatim` requires the default to
+produce at least one high `s` over 24 signatures.
+`test_low_s_is_a_property_of_the_sign_verify_pair` asserts the four-way truth
+table directly. `test_ecdsa_matches_rfc6979_reference` runs the
+specification-derived reference under *both* policies.
 `tests/test_secp256k1_ecdsa_low_s_policy.py` holds the secp256k1 half unchanged.
 
 ---
 
+## INVARIANT-35 — A Selector Must Never Resolve Weaker Than It Was Asked
+
+**Statement.** Any argument that names an algorithm, curve, parameter set or
+security level **must** resolve to exactly what was named or fail. It must
+never fall back to a default, round to a neighbour, or return a plausible
+answer for an input it did not recognise.
+
+Concretely, for every selector in the library:
+
+- an unrecognised value raises (Python) or returns `NULL` / `0` (C);
+- a size or capability query for an unrecognised value returns `0` or `NULL`,
+  never the size of some other parameter set;
+- no selector has a "default" branch that maps unknown input onto a real
+  choice.
+
+**Why.** INVARIANT-7 covers the *availability* axis: no backend, no operation.
+This is the *selection* axis, and nothing covered it until the library grew
+enough parameter sets for it to matter. As of the NIST prime curves and the
+FIPS 203/204 parameter-set work there are nine selectable levels across three
+families, plus SLH-DSA's two — an integer or a string away from each other.
+
+The failure this prevents is quiet and total. A selector that maps an
+unrecognised `"ML-KEM-192"` onto ML-KEM-512, or a mistyped curve id onto
+P-256, produces working code, valid signatures and successful handshakes at a
+security level nobody chose and no test asserts. Unlike a missing backend, it
+never surfaces: the caller believes it asked for category 5 and got category 1,
+and every downstream artefact is well-formed. A downgrade that reports success
+is worse than a hard failure, because only the hard failure gets fixed.
+
+The rule is deliberately absolute rather than "must not resolve *weaker*". A
+selector cannot know which direction is weaker for a given caller — P-521 is
+not simply "stronger" than P-256 for someone whose peer only speaks P-256 —
+and a rule that requires that judgement invites a fallback that argues it got
+the direction right. Resolve exactly, or refuse.
+
+**Enforcement.** In C: `nistp_lookup()`, `kyber_params_for()`,
+`dil_params_for()` and `slhdsa_params_for()` each end in `default: return NULL`
+and every public size/name query propagates that as `0` / `NULL`. In Python:
+`_param_set_id()` (shared by `_ml_kem_id` / `_ml_dsa_id`) and
+`_nistp_curve_id()` raise `ValueError` on any unrecognised value, and reject
+`bool` explicitly — `True` is an `int` in Python and would otherwise index a
+selector table.
+
+Name aliases are permitted and are not a violation: `"secp256r1"`,
+`"prime256v1"` and `"P-256"` denote the same curve, and `"Dilithium3"` denotes
+ML-DSA-65. An alias resolves to the thing it names. What is forbidden is
+resolving something that names *nothing*.
+
+**Verification.** `tests/test_selector_strictness.py` enumerates every selector
+in the library and drives each with the same battery of unrecognised inputs —
+neighbouring-but-invalid integers, plausible-but-wrong names, `bool`, `None`,
+negative values, and the empty string — asserting a raise every time. It also
+asserts the C side returns `0` / `NULL` rather than another set's answer, and
+that the alias tables resolve only to sets that actually exist. Adding a
+selector without adding it to that enumeration fails the test, because the test
+derives its list from the modules rather than from a hand-written literal.
+
+---
+
 _Maintained by Steel Security Advisors LLC._
 _Last updated: 2026-07-27_

ama_cryptography/_integrity_digest.txt

@@ -1 +1 @@
-bcde7df97d18f5d41402b970a65b4050c70eba6690551b30b301d85d1eca2f35
+6ded65965672e4522afc74d154aba84dbc88f7257e0044226896bfa21f6412d1

ama_cryptography/_integrity_signature.py

@@ -15,13 +15,13 @@
 
 # SHA3-256 digest of the package's .py files at build time (raw 32 bytes,
 # hex-encoded for embeddability).
-INTEGRITY_DIGEST_HEX = "bcde7df97d18f5d41402b970a65b4050c70eba6690551b30b301d85d1eca2f35"
+INTEGRITY_DIGEST_HEX = "6ded65965672e4522afc74d154aba84dbc88f7257e0044226896bfa21f6412d1"
 
 # Ephemeral build-time Ed25519 public key (raw 32 bytes, hex-encoded).
-INTEGRITY_PUBKEY_HEX = "61227627013653b6ba224b13fbaeebcfb0f94516a79c148dbf4ece8befd637ec"
+INTEGRITY_PUBKEY_HEX = "781b363cd77e64639d202b05f3b861de1d7ee573db99a4d3a2fa1eb4fdaff79c"
 
 # Ed25519 signature over the raw digest above (raw 64 bytes, hex-encoded).
-INTEGRITY_SIGNATURE_HEX = "5dbc6756de8fc6c95ce11889d3dd5a06547f72775fa47eb8bf0abf72674165110debd0327daa071a6863ab2bb4ef2e9b2db3dd5ef09e8bf09dcfc617d291fd0c"
+INTEGRITY_SIGNATURE_HEX = "3071ac8037c8fbe50195a17b82b5eea64fc5dcce475e12c02bf1ec651496385dd636d24df98ebecf19878752f80e65dc3359ec8ffc70621d518b23de0460fd02"
 
 # Build metadata — informational only, not part of the integrity contract.
 BUILD_PIPELINE_VERSION = "1"

ama_cryptography/exceptions.py

@@ -47,16 +47,38 @@ class AmaCryptographyError(Exception):
     pass
 
 
-class PQCUnavailableError(AmaCryptographyError, RuntimeError):
+class NativeBackendUnavailableError(AmaCryptographyError, RuntimeError):
+    """
+    Raised when an operation needs the native C backend and it is not present.
+
+    This is INVARIANT-7's failure mode expressed as a type: the library refuses
+    to operate rather than substituting anything. It is not specific to
+    post-quantum work — the NIST prime curves, secp256k1 and the classical
+    primitives raise it for the same reason.
+
+    ``PQCUnavailableError`` is a subclass, so existing ``except
+    PQCUnavailableError`` sites keep working and ``except RuntimeError``
+    continues to catch every case. Catch this class when the question is
+    "is the native library present", and the subclass when the answer needs
+    to distinguish which family was asked for.
+
+    To resolve, build the native C library:
+        cmake -B build -DAMA_USE_NATIVE_PQC=ON && cmake --build build
+    """
+
+    pass
+
+
+class PQCUnavailableError(NativeBackendUnavailableError):
     """
     Raised when post-quantum cryptography is required but unavailable.
 
     This exception indicates that a PQC operation was requested but the
     native C backend is not available.
 
-    Inherits from AmaCryptographyError (catch-all root) and RuntimeError
-    (backward compatibility with existing tests and code that expects this
-    exception hierarchy).
+    Inherits from NativeBackendUnavailableError (and transitively from
+    AmaCryptographyError and RuntimeError), so every pre-existing handler
+    shape keeps working unchanged.
 
     To resolve, build the native C library:
         cmake -B build -DAMA_USE_NATIVE_PQC=ON && cmake --build build
@@ -157,6 +179,7 @@ class AmaHSMUnavailableError(AmaCryptographyError, RuntimeError):
 __all__ = [
     "AmaCryptographyError",
     "SecurityWarning",
+    "NativeBackendUnavailableError",
     "PQCUnavailableError",
     "QuantumSignatureUnavailableError",
     "QuantumSignatureRequiredError",