[Cryptography] Montana: a post-quantum time chain and its applications, full source for review

[alejandromontana at tutamail.com]

Dear list,





I would like to put the whole of Montana in front of this list for review: the normative


specification, the reference implementation, the client core and the source of every


application built on it, together with the binaries built from that source.





What the protocol is, in the terms of its own documents:





  1. Post-quantum only. ML-DSA-65 (FIPS 204) signs, ML-KEM-768 (FIPS 203) agrees keys,


     SHA-256 and SHA-3 hash, ChaCha20-Poly1305 (RFC 8439) seals. ECDLP, RSA, classical


     Diffie-Hellman, EdDSA and Schnorr are excluded by the first global invariant.





  2. A person is a secret. Everything of a person derives from one seed drawn on the


     device and shown as 24 words; the seed is health-tested before it becomes anyone,


     and a failing source is refused. No identifier of a person exists in state or on


     the wire.





  3. Value is shielded from genesis. A payment publishes the nullifiers it consumes, the


     commitments it creates, a rate nullifier and a proof of conservation, and nothing


     else. Nullifiers are derived from the position of the leaf in an append-only tree,


     never from sender-chosen randomness, so identical notes still extinguish


     differently. Emission creates a right, redeemed inside a payment nothing


     distinguishes from any other.





  4. The TimeChain is the sequence of cemented windows. A window links to its


     predecessor by the proposal identifier alone and closes when the accumulated cement


     reaches the quorum share; there is no clock, no sequential work and no timeout, and


     two proposals of one height are separated by which proof verifies. A network that


     cannot reach the quorum waits rather than forking.





  5. Delivery has no addresses. Two devices agree a secret by an ML-KEM-768 exchange in


     both directions, fold it with the transcript, and each signs the transcript with its


     ML-DSA-65 identity key; the identity keys travel inside the encapsulation. What


     crosses the wire is cells of one width.





On that core stands an ecosystem for iPhone, iPad, Mac and Android: a messenger (letters,


media, voice and video calls with SFrame-sealed media), a wallet, a Bluetooth mesh, direct


phone-to-phone delivery, a VPN client and a messenger for companies. All of them open the


same person from the same 24 words and link one client core; nothing cryptographic is


reimplemented in an application.





Where everything is:





  Whitepaper (the ecosystem, with references into the specification):


    https://github.com/efir369999/montana_messenger/blob/main/WHITEPAPER.md





  Normative specification (Constitution, Canon, Consensus, Value, Identity, Network, App):


    https://github.com/efir369999/montana_messenger/tree/main/core/docs





  Reference implementation and client core (Rust):


    https://github.com/efir369999/montana_messenger/tree/main/core





  Source of every application:


    https://github.com/efir369999/montana_messenger/tree/main/apps


    https://github.com/efir369999/montana_business





  IPA and APK files, with SHA-256 digests and the commit each source folder is:


    https://github.com/efir369999/montana_messenger/releases/latest


    https://github.com/efir369999/montana_business/releases/latest





  The applications on TestFlight:


    https://testflight.apple.com/join/BHaSYWkz   (Messenger; Android APK in the release)


    https://testflight.apple.com/join/n9UqzRDp   (Wallet)


    https://testflight.apple.com/join/MSMfey6f   (Business)





What a reviewer should know before reading:





  - The specification governs. core/Montana-Core reproduces it, and its build parses the


    values, domain separators and frozen vectors of the set and fails on any divergence.


    core/Code is the client core the applications link; its VERSION.md records the


    specification generation it was written against.


  - One item is open and named at the front of the set: the constraint set of the two


    circuits, bound by hash, with its statements, description format and verifier fixed


    in Canon. Montana-Core/AUDIT.md and Code/docs/SPEC_DEVIATIONS.md list what the green


    build does not hold.


  - ML-DSA-65 and ML-KEM-768 come from libcrux 0.0.10 in Montana-Core and from OpenSSL


    3.5, built from source, in the client core. Montana-Core signs with the deterministic


    variant of FIPS 204 (RND = 32 zero bytes), reproduces the NIST ACVP vectors of both


    primitives, and checks itself differentially against OpenSSL; the client core carries


    its own ACVP known-answer tests.


  - The IPA files are the App Store exports, published to be read, compared with the


    source or re-signed; TestFlight installs them. Node endpoints in the published source


    are documentation addresses (RFC 5737).





I would value the list's reading most on: the binding of the handshake transcript to the


identity keys; nullifiers derived from position; finality by quorum cement with no timeout,


and what it costs liveness under partition; and the health tests on the seed.





https://github.com/efir369999/montana_messenger


—
Alejandro

 «You can’t parallelize your way out of time.»
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20261008/3dde3acd/attachment.htm>