Audited Quartz's crypto surface and found every primitive the QUIC
plan called out for BouncyCastle is already present in commonMain:
- `utils/ciphers/AESGCM.kt` — AES-GCM with AAD (QUIC-TLS AEAD)
- `nip44Encryption/crypto/ChaCha20Poly1305.kt` — pure-Kotlin AEAD
- `nip44Encryption/crypto/Hkdf.kt` + `utils/mac/MacInstance.kt` — HKDF
- `utils/sha256/Sha256.kt` — SHA-256
- `marmot/mls/crypto/X25519.kt` — X25519 ECDH (TLS 1.3 key exchange)
- `marmot/mls/crypto/Ed25519.kt` — Ed25519 signatures
- `utils/SecureRandom.kt`
Plan update highlights:
- "What we delegate" section rewritten to point at Quartz primitives.
- Phase B renamed from "TLS via BouncyCastle" to "TLS 1.3 client state
machine on Quartz primitives"; bumped from 2 to 3 weeks because we
write the state machine ourselves, but eliminates the entire
BC-adapter integration risk.
- "Dependencies to add" section zeroed out — nothing goes in
gradle/libs.versions.toml. The only new primitive is a thin
HKDF-Expand-Label helper on top of existing `MacInstance`, which
we can upstream to Quartz's `Hkdf` as a general `expand(prk,
info, length)`.
- Risk table rewritten: removed BC-specific risks, added
Quartz-specific ones (verify `X25519.dh` against RFC 7748 vector
on Phase B day-1).
- Cert chain signature verification uses JDK `Signature` for RSA +
ECDSA plus Quartz `Ed25519` for Ed25519 leaves.
Total timeline moves from 16-18 weeks to 17-19 weeks — same band,
but with zero external dependencies and zero Maven-resolution risk.
https://claude.ai/code/session_013nVLALALKaHVgHm9u5Cg8D
Claude
1ff951dbb4