Protocol v4: rebuild X3DH and the Double Ratchet (BREAKING)

[ivRodriguezCA]

Rebuilds X3DH and the Double Ratchet as protocol v4, and deletes v3 rather than deprecating it.

This is a hard, deliberate break. Correcting the key agreement changes every key derived downstream
of it, so no version of this fix stays wire-compatible. A v4 receiver rejects a first byte that is
not 0x04 with ERR_UNSUPPORTED_VERSION, there is no migration path and no dual-stack mode, and
existing identities must be re-registered because the identity key type itself changed.

Why

v3 was cryptographically broken, not merely dated. Two of the defects were reported by users and
went unfixed for years:

• Incorrect triple-DH implementation #13 (@digal, May 2019) — X3DH collapsed to a single Diffie-Hellman.
  crypto_kdf_derive_from_key takes const unsigned char k[crypto_kdf_KEYBYTES] and reads exactly
  32 bytes; IRTripleDHService handed it a 96- or 128-byte DH1 ‖ DH2 ‖ DH3 [‖ DH4]. DH2, DH3 and
  DH4 were computed, concatenated, and discarded. DH1 is X25519(IK_A, SPK_B) — both long-lived —
  so the handshake had no forward secrecy and the one-time prekey contributed nothing.
• This is not standart curve25519 algoritm. #12 (@NoVoLuMe, @raojunbo) — the library could not agree a key with standard X25519
  implementations, for two independent reasons: the API took Ed25519 public keys and ran
  crypto_sign_ed25519_pk_to_curve25519 over whatever it was given (discarding the return value, so
  a rejected input left an uninitialized stack buffer in use as a private scalar), and the result
  was BLAKE2b(q ‖ pk_s ‖ pk_r) rather than q.

SPEC.md §14 has the full table: thirteen confirmed defects, plus nine more found while writing the
specification.

Every one of these passed the v3 test suite. In each case both parties agreed — and agreement
was never the property in question. IRTripleDHServiceSpec asserted that Alice's and Bob's shared
keys were equal and 32 bytes long, which is exactly as true of a single DH as of a triple one. That
is the organising constraint of this PR: positive round-trip tests certify nothing about this
protocol.

What this PR contains

Four commits, split by concern:

1. 8d13a6d — libsodium 1.0.13 → 1.0.22, repackaged as an XCFramework. Not a routine bump: the
   vendored libsodium.a had x86_64 and arm64 slices both built for the iOS device platform, so
   no simulator build linked on Apple Silicon. A .a is indexed by architecture alone and
   device-arm64 and simulator-arm64 are the same architecture, so no fat archive can carry both.
   Deployment target 10.3 → 13.0. Supersedes libsodium v1.0.14 #11.
2. 4552ac7 — the protocol rewrite. BREAKING.
3. 9e62be4 — SwiftPM replaces the podspec, README rewritten, CHANGELOG added.
4. 7f41a0c — the frozen conformance vector corpus. See below.

The specification is the actual deliverable

SPEC.md is normative, and the Java, Kotlin and Swift ports now in progress are written against it
rather than against this code. It is what makes "these four interoperate" a checkable claim instead
of an aspiration.

Protocol changes

• HKDF-SHA256 (RFC 5869) everywhere a key is derived — its (ikm, ikm_len) signature makes the
  Incorrect triple-DH implementation #13 truncation inexpressible rather than merely fixed.
• ChaCha20-Poly1305 IETF (RFC 8439) replaces AES-256-CBC + HMAC-SHA256 via CommonCrypto. One
  AEAD call: no encrypt-then-MAC assembly, no separate IV, no MAC comparator, and no Apple-only
  dependency standing between this and the ports.
• Two-key identity: Ed25519 for signing (RFC 8032 pure, never prehashed) and X25519 for ECDH
  (RFC 7748), as separate key pairs. The Ed25519→X25519 conversion is banned outright.
• Domain-separated labels on every derivation, and a transcript hash binding the handshake to
  every key and identifier it used.
• Nominal key types — an Ed25519 public key is not assignable to an X25519 parameter and the
  compiler enforces it.
• Ordered parsing gates in which no offset is ever derived from a received byte. v3 read a
  wire-supplied length and used it as a subdataWithRange: bound.
• Atomic decryption — ratchet step, chain advance, counter increment and skipped-key insert all
  happen on a snapshot committed only after the AEAD authenticates. Otherwise one unauthenticated
  message permanently desynchronises a live session.
• Every return value checked. NSMutableData dataWithLength: zero-fills, so an unchecked RNG
  failure yields an all-zero key that both parties agree on, with nothing to observe.
• An explicit zeroization schedule covering failure exits, not just success paths.
• One injectable clock and CSPRNG, because a frozen conformance suite that reads the wall clock
  has a shelf life of seven days.

Structure

IRSodiumCryptoProvider is the only file permitted to call libsodium; every layer above holds an
id<IRCryptoProvider>. That seam is where a platform crypto backend gets swapped, which is exactly
what the three ports do. tools/lint_banned_apis.py runs as a pre-Sources build phase, so a banned
API, a second crypto_sign_detached call site, or a raw *error = assignment stops the build.

Testing

529 tests, 0 failures, zero source warnings, on a clean build.

The suite deliberately includes property-based tests for the invariants a round-trip cannot see:
that altering any single DH input changes SK, that every message key moves when SK moves, that
every bit flip in a message fails to decrypt, and that a failed authentication leaves session state
byte-identical.

The conformance corpus (7f41a0c)

spec/vectors/*.json — 88 vectors across six files, covering every id SPEC.md §15.3 and §15.4
require. This is the artifact the Java, Kotlin and Swift ports are graded against; they are written
against SPEC.md rather than against this code, so the vectors are the only thing that can catch a
divergence.

• The RFC-anchored vectors are transcribed from RFC 5869, 7748, 8032 and 8439, never produced
  here — a corpus generated entirely by the implementation under test proves self-consistency and
  nothing else. Every value was re-fetched from rfc-editor.org and compared mechanically, and the
  nuntius derivations were independently recomputed in Python from the spec prose: both X3DH
  handshakes end to end, and RATCHET-LINEAR reimplemented from scratch through §6–§9.
• The suite rebuilds the corpus in memory each run and compares byte-for-byte, so drift fails a test
  instead of rewriting the contract. Rewriting needs the explicit .regenerate sentinel, which then
  fails the run on purpose so the diff gets reviewed.
• No vector reads the host clock; the suite runs again with the clock ten years forward.

Building it found two defects in this specification, both of which would otherwise have been
frozen into the contract by §15.6 step 4:

• §3.4 claimed Ed25519 signing is byte-reproducible across libsodium, the JDK and CryptoKit. It
  is not — RFC 8032 §8.2 permits added randomness and CryptoKit takes it. Signing one message three
  times under one seed gives three different valid signatures, none equal to RFC 8032's published
  one. The mandatory RFC8032-ED25519 vector was therefore unpassable by a conformant Swift port.
  Signatures are now verify-side only (§15.5 rule 8): always an input, never an expected output.
• §4.4 claimed CryptoKit performs no small-order check. It does — key agreement throws. The MUST
  is unchanged and now says why: an implementation may not skip its own check because it trusts the
  library underneath, and that trust is exactly what was wrong here, in the direction that sounds
  safe.

Also corrected: X25519-ZERO listed six small-order u-coordinates with bit 255 clear when there are
seven (confirmed from the curve arithmetic, not a copied blacklist), and the §10.3 bundle rejections
are kind: "wire" rather than "state" — a prekey bundle is a §5.4 wire structure, and a port
switching on kind would otherwise hand 251 bytes of bundle to its state-blob parser.

Review guidance

SPEC.md §6 (X3DH) and §7 (Double Ratchet) are the sections worth human attention before this is
tagged 1.0.0; everything else follows from them. §17 records the open risks and deliberate
non-goals, including that the transcript-hash binding has not been externally reviewed.

Addresses #13 and #12.