EXPORT-COMPLIANCE.md — US encryption export controls

Status: measured, 2026-09-01. Checked against primary sources on this date — not recalled from training. Re-verify before submission; export regulations change and this file will go stale.

Not legal advice. The ambiguity in §3 needs export counsel before first submission.

---

> ## ✅ SETTLED — 5 September 2026: exempt, on a good-faith reading > > app/project.yml sets ITSAppUsesNonExemptEncryption: false, and that is the answer every > shipped build carries. This banner previously claimed the opposite; it was wrong about the code. > > Don, 5 Sep 2026: "we already discussed the non-exempt thing ... the controversy was whether our > protocols were somehow not standard but our protocols don't speak to the method of encryption so we > want our best good faith estimate as to our compliance posture without creating undue burden by > over broad interpretation of what is exempt vs non exempt." > > The reasoning. The app defines no cryptography of its own. It uses X25519, Ed25519, > ChaCha20-Poly1305, SHA-256 and AES-GCM, all standard and published. PROTOCOL.md specifies > routing, addressing, tokens and retention -- it does not specify a cipher, a mode, or a key > schedule of its own invention. Implementing a published algorithm in Rust rather than calling the > operating system's copy does not make the algorithm non-standard; the earlier sections of this > document treated it as if it did, and that was the over-broad reading Don is rejecting. > > The functionality is ordinary confidentiality for personal communication: not special-purpose, not > for government or military use, no proprietary cryptography. > > What must stay in agreement. Three places say this, and they must never disagree again: > app/project.yml (false), web/encryption.html §6, and this banner. The website said true > until 5 Sep 2026, which is how the disagreement was found. > > What would reopen it. Shipping a primitive of our own, a non-published algorithm, or a > special-purpose mode. Sections 3 to 6 below are kept as the record of the earlier analysis and its > stricter reading; where they conflict with this banner, this banner is the decision.

---

---

1. Strength is not the axis

Key-length thresholds were the 1990s regime — the 40-bit and 56-bit limits, the PGP prosecution, Bernstein. Those are gone. Using X25519 and ChaCha20-Poly1305 does not put this project in a worse position than weaker choices would, and deliberately weakening anything would buy nothing.

What determines obligations is what kind of item it is, whether the source is public, and where it goes.

Framework: Export Administration Regulations (EAR), administered by the Commerce Department's Bureau of Industry and Security. Encryption software sits in Category 5 Part 2 of the Commerce Control List. This app classifies as ECCN 5D002.

---

2. Two routes, and open source is dramatically simpler

### Route A — publicly available source code

> 15 CFR 742.15(b)(1): "Publicly available encryption source code classified under ECCN 5D002 is > not subject to the EAR."

Not "exempt." Not subject. No annual report, no classification request, no filing — provided the source is genuinely publicly available.

> 15 CFR 742.15(b)(2): notification to BIS and the ENC Encryption Request Coordinator by email is > required only for publicly available source code that "provides or performs non-standard > cryptography."

Discrepancy on record. BIS's own plain-language guidance page states that publicly available source "is not subject to the EAR once the email notification per section 742.15(b) is sent" — presenting notification as a blanket condition. The regulation limits it to non-standard cryptography. BIS's summary is stricter than BIS's rule.

Resolution: if we open-source, send the notification anyway. One email to crypt@bis.doc.gov and enc@nsa.gov with the repository URL. It costs nothing and moots §3's ambiguity entirely, whichever reading is correct.

### Route B — closed source

Export under License Exception ENC §740.17(b)(1), which carries a recurring obligation:

Each product is reported once, in the year it was self-classified. If nothing changed since the prior report, an email saying so suffices.

The second year is where this gets forgotten. Put it in a calendar, not in someone's head.

---

3. The open question — is our protocol "non-standard cryptography"?

EAR Part 772 defines non-standard cryptography as proprietary or unpublished cryptographic functionality, "including encryption algorithms or protocols that have not been adopted or approved by a duly recognized international standards body" — IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA, GSMA.

Our primitives are unambiguously standard. X25519, ChaCha20-Poly1305, HKDF-SHA256, HMAC-SHA256 — all published IETF specifications (PROTOCOL.md §4.1). The project rule against inventing cryptography settles the algorithm question completely.

Our protocol is not standards-body adopted, and will not be. The Envelope, the fixed-layout AAD, the token derivation, the route-discovery state machine — all bespoke.

Two readings:

• Narrow (non-standard means secret or proprietary primitives): we are clearly fine. This is also how the industry operates — the Signal Protocol is not an IETF standard, and Signal and WhatsApp ship without CCATS.
• Literal ("or protocols"): a custom protocol assembled from public parts is arguably reached.

### Working determination, 2 Sep 2026

We self-classify as mass market using standard cryptography, and record the basis here. Don's reading, which drives this: "the nature of the encryption is what their concern is... the content of what is encrypted is not really a protocol that affects the nature of the encryption."

That is right about the axis. Envelope framing, transport selection and fragment reassembly do not change what X25519 or ChaCha20-Poly1305 do, or how hard either is to break. §1 already says strength is not the axis; capability is.

But the argument must not rest on "ours is not a cryptographic protocol," because parts of it are and a knowledgeable reviewer would say so: the handshake is a station-to-station exchange with a signed transcript, the HKDF info strings bind specific material, the AAD layout is fixed for security reasons, and destination tokens are derived from keys and time to be unlinkable. Those determine security properties. A flawed handshake breaks everything regardless of primitive strength.

The basis we actually rely on is the definition's own wording — non-standard cryptography is proprietary or unpublished functionality:

#### Prior art for every mechanism — the concrete basis for "not novel"

Don asked the right question directly: "Novel? Are we novel?" The test is whether each mechanism can be traced to existing published work. Every one can:

Bespoke, not novel — and that is the distinction the regulation turns on. Nothing here is an invention; it is assembled from parts that each carry a citation.

Note also that being un-novel is a security property and not merely a regulatory convenience. Novel cryptography in a shipping product is almost always a mistake, and §4.1's rules — never invent cryptography, and no negotiable cipher suites because negotiation is a downgrade surface — are why this table can be written at all.

The Exposure Notification comparison is the one to lead with: Apple and Google shipped HMAC-derived, epoch-rotating, unlinkable identifiers to billions of devices. That mechanism is not treated as non-standard cryptography.

Why this is a determination we are entitled to make. Self-classification is not a permission granted to us; it is an assessment we make in good faith and document. Certainty about how a third party would read "or protocols" is not the standard and never was. Don: "we cannot know how somebody else will interpret the answer, but we have to answer in good faith." This section, and the published page, are that record.

Still get export counsel before external distribution, and before any French availability (§4). This determination is the working basis for internal testing and for answering Apple honestly; it is not a substitute for review when the stakes rise. Open-sourcing would moot the question entirely via the publicly-available route, which remains the cleanest resolution and is one more argument for it.

---

3a. What Apple's own validation told us, 2 Sep 2026

Two upload attempts and two API refusals settled how this app is actually handled, and the answer is less onerous than §4 implies.

Setting ITSAppUsesNonExemptEncryption: true in Info.plist breaks the upload:

`` Invalid Export Compliance Code. The export compliance key value [] in the app's Info.plist doesn't match the key value of the app's export compliance documentation. ``

Apple looks for a companion ITSEncryptionExportComplianceCode, which exists only for apps holding encryption-declaration paperwork.

Attempting to file that paperwork is refused, and the refusal is the useful part:

`` Cannot create appEncryptionDeclarations unless either containsProprietaryCryptography is True or containsThirdPartyCryptography and availableOnFrenchStore are both True. ``

Our honest answers are proprietary No, third-party Yes, French store No — a combination Apple will not let you file a declaration for, because that combination does not need one. Apple's own validation is confirming the §3 working determination from the other direction: an app using only published third-party standard algorithms, not sold in France, files nothing.

Therefore: the key is omitted from Info.plist and the truthful answer is given per build via PATCH /v1/builds/{id} with usesNonExemptEncryption: true. That is the same honest answer in the place Apple actually wants it for this app's situation.

> Never set the key to false to silence the prompt. That is the false declaration builds 1–4 > carried, and it is what this document exists to prevent. Absent ≠ false: absent means "answered per > build", and the per-build answer is yes.

3b. The question Apple actually asks — §3 is moot in their flow

Answered in App Store Connect for build 5 on 2 Sep 2026. The wording matters, because it is not the EAR wording this document has been wrestling with:

> What type of encryption algorithms does your app implement? > 1. Encryption algorithms that are proprietary or not accepted as standard by international standard > bodies (IEEE, IETF, ITU, etc.) > 2. Standard encryption algorithms instead of, or in addition to, using or accessing the encryption > within Apple's operating system > 3. Both algorithms mentioned above > 4. None of the algorithms mentioned above

Apple asks about ALGORITHMS. The phrase "or protocols" does not appear. The §3 ambiguity — whether a bespoke protocol assembled from standard parts counts as non-standard cryptography — simply does not arise here. Our algorithms are X25519, Ed25519, ChaCha20-Poly1305, HKDF-SHA256 and SHA-256, every one an IETF or FIPS publication, so option 2 is unambiguously correct and required no interpretation.

Second and final question: "Is your app going to be available for distribution in France?" Answered No, which keeps §4's separate French declaration out of scope for the beta. Revisit this before any App Store release that includes France.

Result: build 5 moved from Missing Compliance to Ready to Submit and was assigned to the tester group. No CCATS, no ERN, no BIS filing was requested at any point.

Note for future uploads. Apple's own dialog says the answers can be baked into Info.plist to avoid answering per submission — but that is the route that produced the "Invalid Export Compliance Code" upload failure in §3a, because ITSAppUsesNonExemptEncryption: true alone makes Apple demand a companion code. Answering per build in the TestFlight UI is the working path for this app. The API does not substitute: PATCH /v1/builds/{id} with usesNonExemptEncryption returns HTTP 200 and does not persist.

4. Apple's gate

• ITSAppUsesNonExemptEncryption = YES. We implement a protocol; we are not limited to OS-provided encryption.
• The French declaration is required only if distributing on the App Store in France.
• No CCATS on the industry-standard-algorithm reading (§3).
• ITSEncryptionExportComplianceCode is added to Info.plist only after Apple approves documentation and issues a code — not before.
• Declare in Info.plist rather than answering the questionnaire per upload, or it reappears on every build.

Note for later: a dependency can change the answer even when our own code does not. Every Rust crate we link is part of what we ship.

---

5. Destination restrictions

Independent of any filing. No export to embargoed destinations — currently Cuba, Iran, North Korea, Syria, and specified Ukrainian regions. App Store territory availability handles this operationally, but the obligation is the developer's, not Apple's.

---

6. Decision — Route B, closed source for v1

Settled by Don on 2026-09-01 (DECISIONS.md F7). We are on Route B.

An earlier draft of this file recommended Route A. That recommendation did not account for a possible future sale, and publishing is irreversible: every released version stays licensed forever, while closed → open remains available at any time. Route B costs one CSV filing a year and preserves the choice; Route A saves that filing and forecloses it.

Live obligations from first export (App Store release):

• [ ] Annual self-classification report — due 1 February, prior calendar year, twelve-field CSV, to the ENC Encryption Request Coordinator. Calendared, not remembered.
• [ ] ITSAppUsesNonExemptEncryption = YES in Info.plist
• [ ] French encryption declaration, if distributing in France
• [ ] No CCATS, on the industry-standard-algorithm reading (§3, and §4's middle row)
• [ ] Confirm §3's "or protocols" question with export counsel before first submission

If this is revisited later, Route A remains fully available, and the §742.15(b)(2) email should be sent regardless of which reading of §3 applies — it costs nothing and moots the ambiguity.

Licence caution if Route A is ever taken: a source-available licence (Business Source, PolyForm, or similar) may not qualify as "publicly available," since that turns on unrestricted dissemination. Choosing one could take every downside of publishing with none of the relief. Unverified — check before selecting a licence.

---

7. Sources — retrieved 2026-09-01

• 15 CFR 742.15 — https://www.law.cornell.edu/cfr/text/15/742.15
• BIS, annual self-classification — https://www.bis.gov/learn-support/encryption-controls/annual-self-classification
• BIS, encryption items not subject to the EAR — https://www.bis.gov/learn-support/encryption-controls/encryption-items-not-subject-to-ear
• BIS, Supplement No. 6 to Part 742 — https://www.bis.gov/ear/title-15/subtitle-b/chapter-vii/subchapter-c/part-742/supplement-no-6-part-742-technical
• Apple, export compliance documentation — https://developer.apple.com/help/app-store-connect/reference/app-information/export-compliance-documentation-for-encryption/

English is the reference text; any translation is a convenience. Help is stored on this phone and never contacts anyone.