- ASH: A One-Time Pad Messaging Protocol for Information-Theoretic Security
-
-
- Secure ephemeral messaging with zero infrastructure trust
-
-
- Draft v0.1 · January 2025
-
-
-
-
-
-
Abstract
-
- We present ASH, a messaging protocol that provides information-theoretic security
- through One-Time Pad (OTP) encryption. Unlike computational security approaches,
- OTP guarantees that encrypted messages remain secure regardless of advances in
- computing power or cryptanalytic techniques. ASH addresses the traditional
- limitations of OTP systems through a novel ceremony protocol for secure key
- exchange, bidirectional pad consumption for independent messaging, and a
- zero-trust relay architecture. The protocol is designed for high-security,
- low-frequency communication scenarios where the cost of in-person key exchange
- is justified by the security requirements.
-
-
-
-
-
-
-
-
-
1. Introduction
-
-
- Modern secure messaging systems rely on computational security assumptions.
- Protocols such as Signal, based on the Double Ratchet algorithm, derive their
- security from the presumed difficulty of certain mathematical problems. While
- these systems provide excellent practical security, they cannot offer absolute
- guarantees against future cryptanalytic advances or the development of quantum
- computers capable of breaking current public-key cryptography.
-
-
-
- The One-Time Pad (OTP) remains the only encryption system with a mathematical
- proof of perfect secrecy. First described by Vernam in 1917 and proven secure
- by Shannon in 1949, OTP encrypts each bit of plaintext with a corresponding
- bit of truly random key material, used exactly once. The ciphertext provides
- no information about the plaintext without the key.
-
-
-
- ASH implements OTP encryption for mobile messaging, addressing three
- fundamental challenges:
-
-
-
-
Key distribution — How do parties securely share the pad?
-
Bidirectional communication — How do both parties send messages independently?
-
Infrastructure trust — How do we minimize trust in servers and networks?
-
-
-
- This document describes the ASH protocol design, including the ceremony
- for key exchange, the message encryption format, the relay server architecture,
- and the security properties that result from these design choices.
-
-
-
-
-
-
2. Background
-
-
2.1 One-Time Pad Properties
-
-
- A One-Time Pad provides perfect secrecy when three conditions are met:
-
-
-
-
The key is at least as long as the message
-
The key is truly random
-
The key is never reused
-
-
-
- When these conditions hold, the ciphertext is statistically independent of the
- plaintext. An adversary with infinite computational resources cannot distinguish
- between possible plaintexts—each is equally likely given the ciphertext.
-
-
-
-
Encryption: C = P ⊕ K
-Decryption: P = C ⊕ K
-
-Where:
- P = Plaintext bytes
- K = Key bytes (pad)
- C = Ciphertext bytes
- ⊕ = XOR operation (bitwise exclusive or)
- Figure 1: One-Time Pad encryption and decryption
-
-
-
2.2 Limitations of Traditional OTP Systems
-
-
- Historical OTP systems, such as those used for diplomatic communications during
- the Cold War, required physical courier delivery of key material. This approach
- does not scale to modern mobile communication. ASH addresses this through:
-
-
-
-
QR code-based key transfer during in-person meetings
-
Fountain codes for reliable transfer over lossy visual channels
-
Mnemonic checksums for human-verifiable integrity
-
-
-
2.3 Comparison with Signal Protocol
-
-
-
-
-
Property
-
Signal
-
ASH
-
-
-
-
-
Security basis
-
Computational (ECDH)
-
Information-theoretic (OTP)
-
-
-
Key exchange
-
Remote (network)
-
In-person (QR codes)
-
-
-
Message capacity
-
Unlimited
-
Fixed (pad size)
-
-
-
Quantum resistance
-
Vulnerable
-
Immune
-
-
-
Group messaging
-
Yes
-
No
-
-
-
Media sharing
-
Yes
-
No
-
-
-
-
-
-
-
-
3. System Architecture
-
-
3.1 Component Overview
-
-
- ASH consists of three components with distinct trust levels:
-
- Figure 2: ASH system architecture and trust boundaries
-
-
-
3.2 Core Library
-
-
- The core library is the cryptographic authority. It is implemented in Rust
- with zero external dependencies to minimize supply chain attack surface.
- The core handles:
-
-
-
-
Pad generation from entropy sources
-
OTP encryption and decryption
-
Pad consumption tracking and enforcement
-
Frame encoding for QR transfer
-
Mnemonic checksum generation
-
Secure memory wiping
-
-
-
3.3 Bidirectional Pad Consumption
-
-
- Traditional OTP systems require coordination to avoid key reuse. ASH solves
- this through bidirectional consumption: the initiator consumes pad bytes from
- the beginning, the responder from the end.
-
- Figure 3: Bidirectional pad consumption model
-
-
-
- Each message includes metadata specifying the byte range consumed. Clients
- track both their own and peer's consumption to calculate remaining capacity.
- When consumption fronts meet, the pad is exhausted and no further messages
- can be sent.
-
-
-
3.4 Pad Sizes
-
-
-
-
-
Size
-
Bytes
-
Approx. Messages
-
QR Frames
-
Transfer Time
-
-
-
-
-
Small
-
64 KB
-
~500
-
~44
-
~10 seconds
-
-
-
Medium
-
256 KB
-
~2,000
-
~175
-
~30 seconds
-
-
-
Large
-
1 MB
-
~8,000
-
~700
-
~2 minutes
-
-
-
-
-
-
-
-
4. Ceremony Protocol
-
-
- The ceremony is a one-time key exchange performed when both parties are
- physically present. It establishes the shared pad without relying on any
- network or server infrastructure.
-
- Pad generation combines multiple entropy sources:
-
-
-
-
OS entropy — Cryptographic randomness from the operating system (SecRandomCopyBytes on iOS)
-
Gesture entropy — Touch coordinates and timing from user drawing patterns
-
Sensor entropy — Device accelerometer and gyroscope readings
-
-
-
- This defense-in-depth approach ensures that compromise of any single entropy
- source does not compromise pad randomness. The gesture requirement also
- ensures active user participation in key generation.
-
-
-
4.3 Fountain Codes
-
-
- QR code scanning is inherently lossy—frames may be missed due to motion,
- focus issues, or partial occlusion. ASH uses fountain codes (rateless erasure
- codes) to ensure reliable transfer.
-
-
-
-
Fountain Code Structure:
-
-Source blocks (K blocks):
-┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
-│ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ ... K-1
-└─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘
- │ │ │ │ │ │ │ │
- └─────┴─────┴─────┴─────┴─────┴─────┴─────┴──── Direct transmission
-
-XOR blocks (redundancy):
-┌─────────────┬─────────────┬─────────────┬─────────────┐
-│ 0 ⊕ 3 │ 1 ⊕ 5 │ 2 ⊕ 7 │ 4 ⊕ 6 │ ...
-└─────────────┴─────────────┴─────────────┴─────────────┘
- │ │ │ │
- └─────────────┴─────────────┴─────────────┴──── Recovery blocks
-
-Properties:
- • First K frames = source data (no overhead if received)
- • Additional frames = XOR combinations for recovery
- • Any ~K frames sufficient to reconstruct original
- • No specific ordering required
- • Deterministic: same index always produces same block
- Figure 5: Fountain code block structure
-
-
-
4.4 QR Frame Format
-
-
- Each QR code contains a single fountain-encoded frame:
-
-
-
-
Frame Layout (1516 bytes total):
-┌──────────────────────────────────────────────────────────────┐
-│ Offset │ Size │ Field │
-├────────┼──────┼──────────────────────────────────────────────┤
-│ 0 │ 4 │ Block index (big-endian u32) │
-│ 4 │ 2 │ Source block count (big-endian u16) │
-│ 6 │ 2 │ Block size (big-endian u16) │
-│ 8 │ 4 │ Original data length (big-endian u32) │
-│ 12 │ N │ Block data (1500 bytes) │
-│ 12+N │ 4 │ CRC-32 checksum (big-endian u32) │
-└──────────────────────────────────────────────────────────────┘
-
-The frame is base64-encoded for QR compatibility.
-Total encoded size: ~2021 characters (fits QR Version 23-24 with L correction)
- Figure 6: QR frame binary format
-
-
-
4.5 Mnemonic Verification
-
-
- After transfer, both devices compute a checksum of the pad and encode it as
- six words from a 512-word vocabulary. This provides 54 bits of verification
- entropy (9 bits per word × 6 words).
-
- Users compare these words verbally—a process resistant to man-in-the-middle
- attacks that cannot be performed without physical presence. If the words do
- not match, the ceremony has failed and must be restarted.
-
-
-
4.6 Optional Passphrase Protection
-
-
- The ceremony optionally supports passphrase encryption of QR frames. When enabled,
- frames are encrypted with a key derived from a shared passphrase before display.
- This provides defense against visual observation attacks if the passphrase is
- communicated through a separate secure channel.
-
-
-
-
-
-
5. Messaging Protocol
-
-
5.1 Message Encryption
-
-
- Each message is encrypted by XORing plaintext bytes with the next unused
- pad bytes from the sender's side.
-
- The relay server is designed as a minimal, untrusted component. It performs
- three functions:
-
-
-
-
Temporarily store encrypted message blobs
-
Deliver messages to recipients when they connect
-
Propagate burn signals between devices
-
-
-
- The relay never sees plaintext, never possesses key material, and cannot
- decrypt any content. A complete compromise of the relay reveals only
- encrypted blobs and metadata.
-
-
-
6.2 Authentication Tokens
-
-
- Devices authenticate to the relay using conversation-specific tokens derived
- during the ceremony. Two separate tokens provide defense-in-depth:
-
- Data Loss Warning: The relay server provides temporary storage
- only. Messages are stored in memory by default and may be lost due to server
- restarts, crashes, or resource constraints. ASH does not guarantee message
- delivery. Users should not rely on the relay for persistent storage.
-
-
-
- Messages are stored with a fixed 5-minute TTL. This short duration:
-
-
-
-
Minimizes server-side data exposure
-
Encourages timely message retrieval
-
Reduces storage requirements
-
Limits metadata accumulation
-
-
-
- Clients should poll regularly or use SSE streaming to receive messages
- before expiry. Expired messages are permanently deleted.
- Note: The burn endpoint requires a separate burn_token, not
- the auth_token. This defense-in-depth ensures that knowing
- the auth token alone is insufficient to destroy a conversation.
-
-
-
6.5 Push Notifications
-
-
- The relay can send push notifications to alert users of new messages.
- Push tokens are registered separately and are not linked to conversation
- tokens to minimize metadata exposure.
-
-
-
-
Push Notification Flow:
-
-┌──────────┐ ┌─────────┐ ┌──────────┐ ┌──────────┐
-│ Sender │────►│ Relay │────►│ APNS │────►│ Receiver │
-│ Device │ │ Server │ │ Server │ │ Device │
-└──────────┘ └─────────┘ └──────────┘ └──────────┘
- │
- │ Push contains:
- │ • "New message" (no content)
- │ • Silent push (no visible alert)
- │
- │ Push does NOT contain:
- │ • Message content
- │ • Sender identity
- │ • Conversation identifier
-
-Privacy note:
- APNS knows that the device received a push from ASH.
- APNS does not know message content or conversation details.
- Figure 14: Push notification architecture
-
-
-
6.6 Rate Limiting and DoS Protection
-
-
- The relay implements limits to prevent abuse:
-
-
-
-
-
-
Limit
-
Default
-
Purpose
-
-
-
-
-
Max ciphertext size
-
8 KB
-
Prevent oversized message attacks
-
-
-
Max queued messages/conversation
-
50
-
Prevent queue flooding
-
-
-
Max conversations
-
100,000
-
Prevent memory exhaustion
-
-
-
Inactive conversation TTL
-
24 hours
-
Auto-cleanup stale registrations
-
-
-
Message TTL
-
5 minutes
-
Limit storage duration
-
-
-
-
-
- Additional rate limiting (requests per second, IP blocking) should be
- applied at the HTTP layer (nginx, Cloudflare, etc.).
-
-
-
-
-
-
7. Security Properties
-
-
7.1 Guarantees
-
-
-
Perfect Secrecy
-
Ciphertext reveals no information about plaintext without the pad. This is proven mathematically, not assumed.
-
-
Forward Secrecy
-
Compromise of the device after a message is sent cannot reveal that message's plaintext—the pad bytes were destroyed.
-
-
Future Secrecy
-
Unlike computational systems, no future advances in computing or mathematics can break past messages.
-
-
Relay Compromise Resistance
-
Full relay server compromise reveals only encrypted blobs and timing metadata.
-
-
No Key Escrow
-
No third party possesses key material. No recovery mechanism exists.
-
-
-
7.2 Non-Guarantees
-
-
-
Anonymity
-
ASH does not hide that communication occurred. Metadata (timing, message sizes) is visible to the relay and network observers.
-
-
Device Security
-
A compromised device can read messages before encryption or after decryption.
-
-
Coercion Resistance
-
Users can be compelled to decrypt messages while the pad exists.
-
-
Availability
-
Relay downtime prevents message delivery. Messages may be lost.
-
-
Participant Trust
-
ASH cannot prevent screenshots or betrayal by conversation partners.
-
-
-
- For a detailed threat model, see the Security Model document.
-
-
-
-
-
-
8. Data Lifecycle
-
-
8.1 Data Storage Locations
-
-
-
Data at Rest:
-
-┌─────────────────────────────────────────────────────────────┐
-│ CLIENT DEVICE │
-├─────────────────────────────────────────────────────────────┤
-│ │
-│ iOS Keychain (encrypted): │
-│ ├── Pad bytes (remaining unused portion) │
-│ ├── Consumption cursors (initiator/responder offsets) │
-│ └── Conversation metadata (name, creation date) │
-│ │
-│ App Sandbox (encrypted): │
-│ └── Message history (if persistence enabled) │
-│ │
-│ NOT stored on device: │
-│ • Used pad bytes (zeroed immediately after use) │
-│ • Decrypted message content (memory only) │
-│ │
-└─────────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────────┐
-│ RELAY SERVER │
-├─────────────────────────────────────────────────────────────┤
-│ │
-│ In-memory storage (default): │
-│ ├── Encrypted message blobs (TTL-bounded) │
-│ ├── Token hashes (SHA-256, not raw tokens) │
-│ └── Active SSE connections │
-│ │
-│ NOT stored on relay: │
-│ • Plaintext message content │
-│ • Pad bytes or derived keys │
-│ • Raw tokens (only hashes stored) │
-│ • Long-term message archives │
-│ │
-│ ⚠ Data may be lost on server restart │
-│ │
-└─────────────────────────────────────────────────────────────┘
- Figure 15: Data storage locations
-
-
-
8.2 Data Destruction
-
-
-
-
-
Event
-
Data Destroyed
-
Method
-
-
-
-
-
Message sent
-
Used pad bytes
-
Volatile zero-write
-
-
-
Message read
-
Plaintext (memory)
-
Memory deallocation
-
-
-
Burn initiated
-
All pad material
-
Multiple overwrites
-
-
-
TTL expiry
-
Relay stored blob
-
Memory deallocation
-
-
-
App uninstall
-
Keychain entries
-
OS-managed deletion
-
-
-
-
-
8.3 iOS Backup Considerations
-
-
- Pad material is stored in the iOS Keychain with attributes that exclude it
- from device backups. This prevents pad leakage through iCloud or iTunes
- backups. Users should be aware that:
-
-
-
-
Restoring from backup will NOT restore conversations
-
Device migration will NOT transfer conversations
-
Each device maintains independent pad state
-
-
-
-
-
-
9. Limitations
-
-
- ASH makes explicit trade-offs that limit its applicability:
-
-
-
-
-
-
Limitation
-
Rationale
-
-
-
-
-
Physical meeting required
-
Secure key exchange without trusting infrastructure
-
-
-
Finite message capacity
-
OTP requires key material equal to message length
-
-
-
Two-party only
-
Group OTP would require O(n²) key material
-
-
-
Text and location only
-
Media would exhaust pad rapidly
-
-
-
No key recovery
-
Recovery mechanisms create escrow risks
-
-
-
No offline messaging
-
Relay required for asynchronous delivery
-
-
-
Messages may be lost
-
Relay provides temporary storage only
-
-
-
-
-
- These limitations are intentional. ASH is not a general-purpose messenger.
- It serves specific high-security scenarios where these trade-offs are acceptable.
-
-
-
-
-
-
10. Applications
-
-
- ASH is designed for scenarios where:
-
-
-
-
Parties can meet in person initially
-
Communication is infrequent but high-stakes
-
Future cryptanalytic advances are a concern
-
Infrastructure cannot be fully trusted
-
Message delivery is not time-critical
-
-
-
- Example use cases include journalist-source communication, whistleblower
- coordination, human rights documentation, and personal safety scenarios.
-
-
-
- Ethical Notice: ASH is designed for legitimate privacy needs.
- Users are responsible for ensuring their use complies with applicable laws
- and does not facilitate harm. See the Ethics Statement
- for guidelines.
-
-
-
-
-
-
References
-
-
-
- Shannon, C. E. (1949). "Communication Theory of Secrecy Systems."
- Bell System Technical Journal, 28(4), 656-715.
-
-
- Vernam, G. S. (1926). "Cipher Printing Telegraph Systems for Secret Wire
- and Radio Telegraphic Communications." Journal of the AIEE, 45(2), 109-115.
-
-
- MacKay, D. J. C. (2005). "Fountain codes." IEE Proceedings-Communications,
- 152(6), 1062-1068.
-
-
- Cohn-Gordon, K., et al. (2020). "A Formal Security Analysis of the Signal
- Messaging Protocol." Journal of Cryptology, 33(4), 1914-1983.
-
-
- Luby, M. (2002). "LT Codes." Proceedings of the 43rd Annual IEEE
- Symposium on Foundations of Computer Science, 271-280.
-
-
-
-
-
-
-
Appendix A: Cryptographic Primitives
-
-
- ASH uses the following cryptographic primitives, all implemented without
- external dependencies:
-
-
-
-
-
-
Primitive
-
Purpose
-
Implementation
-
-
-
-
-
XOR
-
OTP encryption/decryption
-
Bitwise exclusive-or
-
-
-
CRC-32
-
Frame integrity checks
-
Polynomial 0xEDB88320
-
-
-
SHA-256
-
Token derivation, mnemonic generation
-
OS-provided (CommonCrypto)
-
-
-
Volatile zero
-
Secure memory wiping
-
Compiler barrier + write
-
-
-
-
-
-
-
-
- This document describes the ASH protocol design. Implementation details
- may vary. For security-critical deployments, review the source code and
- conduct independent security audits. The protocol is under active development
- and this specification may be updated.
-
-
-
diff --git a/website/src/pages/ethics.astro b/website/src/pages/ethics.astro
index b8ebd83..9f7aea9 100644
--- a/website/src/pages/ethics.astro
+++ b/website/src/pages/ethics.astro
@@ -1,238 +1,317 @@
---
import Layout from '../layouts/Layout.astro'
+import InfoBox from '../components/InfoBox.astro'
---
-
-
-
-
- Ethics Statement
-
-
- Ethical position, intended uses, and design constraints
-
-
-
-
-
-
- ASH is a technical project, but it exists in a social and moral context.
- Strong privacy tools present an inherent dual-use challenge: the same
- properties that protect legitimate users can also shield harmful actors.
- This document describes our ethical position and the design decisions
- made in response to this challenge.
+
+
+
+
+
+ Ethics Statement
+
+
Ethical Position
+
+ ASH is a technical project, but it exists in a social and moral context. This document describes our ethical position and design constraints.
+
+
+
+
+
+ Strong privacy tools present an inherent dual-use challenge: the same properties that protect legitimate users can also shield harmful actors. We acknowledge this reality and have made deliberate design decisions in response.
-
-
-
-
1. Intended Use Cases
+
+
+
Intended Use Cases
-
- ASH is designed for situations where confidentiality is critical and
- trust in infrastructure is limited. The following use cases motivated
- the project's design:
-
+
+ ASH is designed for situations where confidentiality is critical and trust in infrastructure is limited:
+
-
-
Journalistic Source Protection
-
- Reporters communicating with sources who require confidentiality to
- avoid professional, legal, or personal consequences.
-
-
-
Whistleblower Communication
-
- Individuals disclosing wrongdoing to trusted parties while minimizing
- the risk of identification or retaliation.
-
-
-
Human Rights Work
-
- Activists, advocates, and documenters operating in environments where
- surveillance poses a threat to personal safety.
-
-
-
Personal Safety
-
- Individuals in situations where secure communication is necessary for
- their physical or psychological well-being.
-
-
-
-
- These use cases share common characteristics: communication is infrequent,
- parties can meet in person to establish trust, and the cost of compromise
- is high.
-
-
+
+
+
Journalistic Source Protection
+
+ Reporters communicating with sources who require confidentiality to avoid professional, legal, or personal consequences.
+
+
+
+
Whistleblower Communication
+
+ Individuals disclosing wrongdoing to trusted parties while minimizing the risk of identification or retaliation.
+
+
+
+
Human Rights Work
+
+ Activists, advocates, and documenters operating in environments where surveillance poses a threat to personal safety.
+
+
+
+
Personal Safety
+
+ Individuals in situations where secure communication is necessary for their physical or psychological well-being.
+
+
+
-
-
-
2. Acknowledgment of Misuse Potential
+
+ These use cases share common characteristics: communication is infrequent, parties can meet in person, and the cost of compromise is high.
+
+
-
- We acknowledge that any strong privacy tool can be misused. This risk is
- real and must be stated explicitly:
-
+
+
+
Acknowledgment of Misuse Potential
-
-
Coordination of criminal activity
-
Harassment or abuse
-
Concealment of harmful behavior
-
Evasion of legitimate oversight
-
-
-
- We do not claim that ASH prevents misuse. We do claim that ASH's design
- intentionally incorporates constraints that reduce certain categories of
- misuse while preserving utility for legitimate purposes.
-
-
+
+
+ We acknowledge that any strong privacy tool can be misused. This risk is real and must be stated explicitly.
+
+
-
-
-
3. Ethical Design Constraints
+
Potential misuse includes:
-
- The following design decisions deliberately limit ASH's potential for
- harmful use:
-
+
+
Coordination of criminal activity
+
Harassment or abuse
+
Concealment of harmful behavior
+
Evasion of legitimate oversight
+
-
-
-
-
Constraint
-
Rationale
-
-
-
-
-
No network anonymity
-
ASH does not hide that communication is occurring
-
-
-
One-to-one only
-
No groups, channels, or broadcast capabilities
-
-
-
Physical meeting required
-
Cannot be used by parties who have never met
-
-
-
No automation
-
Every action requires explicit user participation
-
-
-
No stealth modes
-
ASH is visible when running; no hidden operation
-
-
-
No deniability claims
-
We do not market or design for plausible deniability
-
-
-
Finite capacity
-
Fixed pad size limits total communication volume
-
-
-
-
-
- ASH favors deliberate, visible, human-driven interaction over
- convenience or scale. This design philosophy reduces the tool's utility
- for mass coordination of harmful activities while preserving its value
- for the intended use cases.
-
-
+
+ We do not claim that ASH prevents misuse. We do claim that ASH's design intentionally incorporates constraints that reduce certain categories of misuse while preserving utility for legitimate purposes.
+
+
-
-
-
4. Project Commitments
+
+
+
Ethical Design Constraints
-
- The ASH project commits to the following constraints:
-
+
+ The following design decisions deliberately limit ASH's potential for harmful use:
+
-
-
We will not add features designed to evade law enforcement
-
We will not provide instructions for illegal activity
-
We will not market the tool as "untraceable" or "anonymous"
-
We will not optimize for scale, virality, or growth
-
We will not integrate surveillance evasion techniques
-
We will not accept funding that compromises these principles
-
-
-
- If a requested feature would meaningfully increase the risk of harm,
- it will not be implemented—regardless of its technical feasibility or
- user demand.
-
-
+
+
+
+
+
Constraint
+
Rationale
+
+
+
+
+
No network anonymity
+
ASH does not hide that communication is occurring
+
+
+
One-to-one only
+
No groups, channels, or broadcast capabilities
+
+
+
Physical meeting required
+
Cannot be used by parties who have never met
+
+
+
No automation
+
Every action requires explicit user participation
+
+
+
No stealth modes
+
ASH is visible when running; no hidden operation
+
+
+
No deniability claims
+
We do not market or design for plausible deniability
+
+
+
Finite capacity
+
Fixed pad size limits total communication volume
+
+
+
+
-
-
-
5. Responsibility Model
+
+ ASH favors deliberate, visible, human-driven interaction over convenience or scale.
+
+
-
- Ethical responsibility for ASH is distributed between project authors
- and users:
-
+
+
+
What ASH Will NOT Do
-
5.1 Project Authors
-
-
Provide honest, accurate documentation
-
Make accurate security claims without exaggeration
-
Clearly communicate limitations and non-guarantees
-
Refuse features that increase potential for harm
-
Respond appropriately to identified misuse patterns
-
-
-
5.2 Users
-
-
Use the tool lawfully and ethically
-
Understand and accept the tool's limitations
-
Take responsibility for their choice of conversation partners
-
Not use ASH to facilitate harm to others
-
-
-
- ASH cannot technically enforce user compliance with ethical guidelines.
- However, the design constraints described above reduce the tool's utility
- for large-scale or anonymous harmful activity.
-
-
+
The ASH project commits to the following constraints:
-
-
-
6. Closing Statement
+
+
+
+
+
+ Add features designed to evade law enforcement
+
+
+
+
+
+ Provide instructions for illegal activity
+
+
+
+
+
+ Market the tool as "untraceable" or "anonymous"
+
+
+
+
+ Accept funding that compromises these principles
+
+
-
- ASH exists to make careful communication possible, not effortless secrecy.
-
+
+ If a requested feature would meaningfully increase the risk of harm, it will not be implemented — regardless of technical feasibility or user demand.
+
+
-
- Ethics are not a feature—they are a constraint on what we will build.
- If at any point the project's direction conflicts with this ethical
- position, the correct action is to stop, reconsider, and possibly not
- proceed.
-
+
+
+
Responsibility Model
-
- We believe that privacy is a human right and that tools enabling private
- communication serve important social functions. We also believe that
- tool designers bear some responsibility for how their tools are used,
- and that this responsibility is best discharged through thoughtful
- design constraints rather than surveillance or backdoors.
-
-
-
-
-
-
- This ethics statement is a living document. It may be updated as we
- learn more about how ASH is used and as social contexts evolve.
- Substantive changes will be documented in the project changelog.
-
+
+ Ethical responsibility for ASH is distributed between project authors and users:
+
+
+
+
+
Project Authors
+
+
+
+
+
+ Provide honest, accurate documentation
+
+
+
+
+
+ Make accurate security claims without exaggeration
+
+
+
+
+
+ Clearly communicate limitations
+
+
+
+
+
+ Refuse features that increase harm potential
+
+
+
+
+
+
Users
+
+
+
+
+
+ Use the tool lawfully and ethically
+
+
+
+
+
+ Understand and accept limitations
+
+
+
+
+
+ Take responsibility for partner choice
+
+
+
+
+
+ Not use ASH to facilitate harm
+
+
+
+
+
+
+
+
+
Closing Statement
+
+
+
+ ASH exists to make careful communication possible, not effortless secrecy.
+
+
+
+
+ Ethics are not a feature — they are a constraint on what we will build. If at any point the project's direction conflicts with this ethical position, the correct action is to stop, reconsider, and possibly not proceed.
+
+
+
+ We believe that privacy is a human right and that tools enabling private communication serve important social functions. We also believe that tool designers bear responsibility for how their tools are used, and that this responsibility is best discharged through thoughtful design constraints rather than surveillance or backdoors.
+
+
+
+
+
+
+ This ethics statement is a living document. For technical details, see Whitepaper. For security analysis, see Security Model.
+
+
diff --git a/website/src/pages/index.astro b/website/src/pages/index.astro
index 6a515ce..2f90ed2 100644
--- a/website/src/pages/index.astro
+++ b/website/src/pages/index.astro
@@ -1,565 +1,726 @@
---
import Layout from '../layouts/Layout.astro'
+import Button from '../components/Button.astro'
+import Section from '../components/Section.astro'
+import FeatureCard from '../components/FeatureCard.astro'
+import PhoneMockup from '../components/PhoneMockup.astro'
---
-
-
-
-
One-Time Pad Encryption
-
- Messages that
- cannot be broken.
-
-
- ASH uses the only encryption mathematically proven to be unbreakable.
- Not today. Not with quantum computers. Not ever.
-
- Every messaging app you use relies on encryption that could be broken
- tomorrow. Mathematical assumptions. Computational hardness. Quantum
- vulnerability. Your most sensitive conversations deserve better.
-
-
-
-
-
Other Apps
-
-
Security based on math problems that might be hard
-
Vulnerable to quantum computers
-
Keys generated remotely
-
Trust the server infrastructure
-
"Secure enough" for most people
-
+
+
+
+
+
+
+ One-Time Pad Encryption
+
+
+ The only encryption that's
+ truly unbreakable
+
+
+ Perfect secrecy proven by mathematics. Not vulnerable to quantum computers. Not now. Not ever.
+
+
+ ASH uses the One-Time Pad cipher — the only encryption method with mathematically proven security. Unlike modern cryptography that relies on computational hardness, OTP provides information-theoretic security that no amount of computing power can break.
+
+
+
+
+
-
-
ASH
-
-
Security proven mathematically (Shannon, 1949)
-
Immune to quantum attacks
-
Keys exchanged in person
-
Server sees only encrypted noise
-
Perfect secrecy, no compromises
-
+
+
+
+
+
+
+
+
+
-
-
How ASH Works
-
-
-
-
1
-
-
Meet in Person
-
- You and your contact meet face-to-face. This is the only way to
- establish trust without relying on servers or networks that could
- be compromised.
-
-
+
+
+
+ How It Works
+
Four steps to perfect secrecy
+
+ ASH takes a fundamentally different approach to secure messaging. Instead of relying on complex mathematical problems that might one day be solved, ASH uses a simple but provably unbreakable method.
+
-
-
2
-
-
Exchange the Pad
-
- Your phone generates a random encryption pad. You transfer it via
- QR codes. Six spoken words confirm success. No internet involved.
+
+
+
1
+
Meet in Person
+
+ Meet your contact face-to-face. This is the foundation of trust — no servers, no third parties, just two people who can verify each other's identity directly.
-
-
-
-
3
-
-
Message Securely
-
- Each message consumes part of the pad and is destroyed after use.
- Even if someone records everything, they get nothing but random noise.
+
+
2
+
Exchange Keys
+
+ Scan QR codes to share a unique encryption pad. This happens completely offline — the key material never touches the internet, making interception impossible.
-
-
-
-
4
-
-
Burn When Done
-
- When you're finished, burn the conversation. All key material is
- destroyed. Past messages become permanently unrecoverable.
+
+
3
+
Message Securely
+
+ Each message consumes unique bytes from your shared pad. Once used, those bytes are permanently destroyed — providing perfect forward secrecy for every message.
+
+
+
+
4
+
Burn When Done
+
+ When your conversation is complete, burn the remaining key material. All evidence of the conversation is permanently destroyed — messages become mathematically unrecoverable.
-
-
-
Security Properties
-
-
-
-
Perfect Secrecy
-
- Ciphertext reveals zero information about plaintext.
- Proven by Claude Shannon in 1949.
+
+
+
+
+ Interactive Demo
+
See the ASH protocol in action
+
+ Watch how ASH uses a shared One-Time Pad for secure bidirectional communication. Alice and Bob each consume key bytes from opposite ends — ensuring their messages never collide.
-
-
Forward Secrecy
-
- Key material is destroyed after each message.
- Compromise later reveals nothing.
-
-
+
+
+
+
+
Shared One-Time Pad
+
64 bytes shown (actual pads are 32KB–1MB)
+
+
+
-
-
Quantum Immune
-
- No algorithm, including quantum, can break OTP.
- Your messages stay secure forever.
-
-
+
+
+
+
+
+
+
+
+ Alice (from start)
+
+
+
+ Available
+
+
+
+ Bob (from end)
+
+
+
-
-
Zero Trust Infrastructure
-
- Servers never see keys or plaintext.
- Full compromise reveals only noise.
-
+
+
+
+
+
+
A
+
+
Alice (Initiator)
+
Encrypts from pad start →
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
B
+
+
Bob (Responder)
+
← Encrypts from pad end
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
0
+
Alice used
+
+
+
64
+
Bytes remaining
+
+
+
0
+
Bob used
+
+
+
+
+
+
How bidirectional encryption works
+
+
+
+ 1
+
+
Shared secret. During an in-person ceremony, Alice and Bob exchange an identical One-Time Pad via QR codes. This pad is their shared secret — never transmitted over any network.
+
+
+
+ 2
+
+
Opposite consumption. Alice encrypts using bytes from the start of the pad. Bob encrypts using bytes from the end. This ensures they never use the same bytes — critical for OTP security.
+
+
+
+ 3
+
+
One-time use. Each byte is used exactly once, then destroyed. Even if the pad is later compromised, already-sent messages cannot be decrypted — perfect forward secrecy.
+
+
+
+
+
-
-
No Key Recovery
-
- No backdoors. No escrow. No master keys.
- Only you and your contact can decrypt.
+
+
+
+
+ The App
+
Simple, focused, secure
+
+ ASH is designed with one purpose: private conversations that stay private. Every feature serves security, every screen is intentional. No bloat, no distractions — just bulletproof communication.
-
-
Open Source
-
- Core cryptographic library is public.
- Zero external dependencies. Audit it yourself.
-
+
+
+
+
+
+
+
+
+
+
Screenshot placeholder
+
+
+
+
Conversation List
+
+ Your secure conversations at a glance. See remaining pad capacity, last activity, and quickly access any conversation. Color-coded for easy identification.
+
+
+
+
+
+
+
+
+
+
+
+
Screenshot placeholder
+
+
+
+
QR Ceremony
+
+ Exchange encryption keys face-to-face via QR codes. The ceremony is completely offline — your shared secret never touches the internet. Verify with a 6-word mnemonic.
+
+
+
+
+
+
+
+
+
+
+
+
Screenshot placeholder
+
+
+
+
Secure Chat
+
+ Messages encrypted with your One-Time Pad. Each message consumes unique key bytes that are destroyed after use. See your remaining capacity and message status.
+
+
+
+
+
+
+
+
+
+
+
+
Screenshot placeholder
+
+
+
+
Entropy Collection
+
+ Generate truly random keys by drawing on screen. Your gestures combine with system randomness to create unpredictable encryption keys. Watch entropy accumulate visually.
+
+
+
+
+
+
+
+
+
+
+
+
Screenshot placeholder
+
+
+
+
Mnemonic Verification
+
+ Verify your key exchange with a human-readable 6-word checksum. Both parties see the same words — speak them aloud to confirm your shared secret matches perfectly.
+
+
+
+
+
+
+
+
+
+
+
+
Screenshot placeholder
+
+
+
+
Burn Everything
+
+ Permanently destroy your conversation with one tap. All key material is wiped, making past messages mathematically unrecoverable. Both parties are notified instantly.
+
+
-
-
-
Who Is ASH For?
-
- ASH is not a replacement for Signal or WhatsApp. It's a specialized tool
- for situations where the cost of compromise is extremely high.
-
-
-
-
-
Journalists
-
Protect sources who risk everything to share information with you.
-
-
-
Whistleblowers
-
Communicate with trusted parties without leaving cryptographic traces.
-
-
-
Human Rights Workers
-
Document and coordinate in environments where surveillance is life-threatening.
+
+
+
+ Security
+
What makes ASH different
+
+ Most "secure" messaging apps rely on computational security — problems that are hard but not impossible to solve. ASH is fundamentally different. Here's what that means for you.
+
+
+
+
+
+ Ciphertext reveals zero information about your message. This isn't a claim — it's a mathematical proof by Claude Shannon in 1949. The gold standard of cryptography.
+
+
+ Key bytes are destroyed after each message. Even if someone compromises your device tomorrow, they cannot decrypt messages you sent today. Every message is protected independently.
+
+
+ Quantum computers will break RSA, ECC, and most modern encryption. OTP is immune because it doesn't rely on mathematical hardness — it's information-theoretic security.
+
+
+ Our servers never see your keys or plaintext. They relay encrypted blobs and nothing more. Even if we're compromised, hacked, or compelled — we have nothing to give.
+
+
+ No key recovery. No escrow. No master keys. No "lawful access" capabilities. The math doesn't allow it, and we wouldn't build it if it did. Only you can decrypt your messages.
+
+
+ The core cryptographic library is public on GitHub. Zero external dependencies. Every line of security-critical code is auditable. Trust, but verify.
+
+
+
+
+
+
+
+
+ Comparison
+
Why not Signal or WhatsApp?
+
+ Signal and WhatsApp are excellent apps with strong security for everyday use. But they rely on computational assumptions that may not hold forever. ASH is for when "probably secure" isn't enough.
+
-
-
Anyone with High-Stakes Privacy Needs
-
When "probably secure" isn't good enough.
+
+
+
+
+
Signal / WhatsApp
+
ASH
+
+ {[
+ ['Security basis', 'Computational hardness', 'Mathematical proof'],
+ ['Quantum resistant', 'Vulnerable to Shor\'s algorithm', 'Completely immune'],
+ ['Key exchange', 'Remote via servers', 'In-person via QR codes'],
+ ['Server trust', 'Servers see metadata', 'Servers see only noise'],
+ ['Future security', 'Depends on unsolved problems', 'Guaranteed by information theory']
+ ].map(([label, other, ash]) => (
+
+
{label}
+
{other}
+
{ash}
+
+ ))}
+
+
+ This isn't about Signal being bad — it's excellent. ASH serves a different threat model for people who need absolute guarantees.
+
+
+
+
+ Who It's For
+
When "probably secure" isn't enough
+
+ ASH isn't for everyone. It requires meeting in person and has limited message capacity. But for certain situations, these trade-offs are more than worth it.
+
+
+
+
+
+ Protect sources who risk their careers, freedom, or lives to share information. When source protection is paramount, mathematical certainty matters.
+
+
+ Communicate with trusted parties while minimizing digital footprints. When exposing wrongdoing, you need encryption that can't be broken even years later.
+
+
+ Coordinate safely in environments where surveillance is pervasive and life-threatening. When the stakes are highest, settle for nothing less than proven security.
+
+
+ Negotiate deals, discuss strategy, or share sensitive information when the cost of compromise is catastrophic. Perfect secrecy for perfect discretion.
+
+
+
+
-
-
Honest Trade-offs
-
- Perfect security requires real constraints. ASH is intentionally limited.
-
-
-
-
-
Limitation
-
Physical meeting required
-
Secure key exchange without trusting networks
-
-
-
Limitation
-
Finite message capacity
-
OTP requires key material equal to message length
-
-
-
Limitation
-
Two people only
-
Groups would require exponential key material
+
+
+
+ Trade-offs
+
Honest about constraints
+
+ Perfect security requires real limitations. We believe in being upfront about them. These aren't bugs — they're features that make the security guarantees possible.
+
-
-
Limitation
-
Text and location only
-
Media would exhaust the pad rapidly
+
+
+ {[
+ ['Physical meeting required', 'Key exchange happens offline via QR codes. This prevents any network-based attack on key distribution — the foundation of OTP security.'],
+ ['Finite message capacity', 'OTP requires one key byte per message byte. Choose pad sizes from 32KB (~25 messages) to 1MB (~800 messages) during the ceremony.'],
+ ['Two people only', 'Group encryption would require sharing keys with multiple parties, exponentially increasing attack surface. ASH is strictly one-to-one.'],
+ ['Text and location only', 'Photos and videos would exhaust your pad quickly. ASH focuses on what matters most: secure text communication and emergency location sharing.']
+ ].map(([constraint, reason]) => (
+
+
{constraint}
+
{reason}
+
+ ))}
-
-
-
Ready for Perfect Secrecy?
-
- Download ASH for iOS and establish your first secure conversation.
-
+ Download ASH and establish your first mathematically unbreakable conversation.
+
+
+
+
+
-
diff --git a/website/src/pages/security.astro b/website/src/pages/security.astro
index 0077fb0..0a1db16 100644
--- a/website/src/pages/security.astro
+++ b/website/src/pages/security.astro
@@ -1,293 +1,392 @@
---
import Layout from '../layouts/Layout.astro'
+import InfoBox from '../components/InfoBox.astro'
+import Diagram from '../components/Diagram.astro'
---
-
-
-
-
- Security Model
-
-
- Threat model, guarantees, and limitations
-
-
-
-
-
-
- This document describes the security properties of the ASH protocol.
- ASH is designed to reduce risk, not eliminate it. Understanding what
- ASH protects against—and what it does not—is essential for appropriate use.
-
-
-
-
Design Philosophy
-
- ASH assumes that humans make mistakes, software is fallible, and infrastructure
- should not be trusted. Security properties must be understandable by users,
- not hidden in cryptographic black boxes. The system favors explicit user
- actions over automatic background operations.
+
+
+
+
+
+ Security Model
+
+
Threat Model & Guarantees
+
+ What ASH protects against, what it doesn't, and why. Security is not a promise — it is a set of clearly defined limits.
-
-
-
-
1. Threat Model
+
+
+
Design Philosophy
+
+ ASH assumes humans make mistakes, software is fallible, and infrastructure cannot be trusted. Security properties must be understandable by users, not hidden in cryptographic black boxes.
+
+
-
- ASH is designed to protect against the following adversaries:
-
+
+
+
Threat Model
-
1.1 Network Observers
-
- An adversary who can observe, record, and analyze all network traffic between
- clients and the relay server. This includes ISPs, nation-state surveillance
- programs, and compromised network infrastructure.
-
-
- Protection: All message content is encrypted with OTP before
- transmission. Network observers see only encrypted blobs and metadata (timing,
- message sizes).
-
+
+ ASH is designed to protect against the following adversaries:
+
-
1.2 Compromised Relay Server
-
- An adversary who has complete control of the relay server, including access
- to all stored data, logs, and the ability to modify server behavior.
-
-
- Protection: The relay never possesses key material. Compromise
- reveals only encrypted blobs, conversation identifiers, and timing metadata.
- The relay cannot decrypt messages or forge valid encrypted content.
-
- Adversaries with access to quantum computers or future mathematical breakthroughs
- that render current computational cryptography insecure.
-
-
- Protection: OTP provides information-theoretic security.
- Perfect secrecy is proven mathematically, not assumed based on computational
- hardness. No future advances in computing can break OTP-encrypted messages.
-
-
+
+
+
+
+
+
+
Compromised Relay
+
+
Full server control, access to storage, logs, ability to modify behavior
+
+
+
Relay never possesses key material. Cannot decrypt or forge.
+
+
-
-
-
2. Security Guarantees
+
+
+
+
+
+
+
Future Adversary
+
+
Quantum computers, mathematical breakthroughs, new cryptanalysis techniques
- When used correctly, ASH provides the following security properties:
-
+
+
+
+
+
+
+
+
All See Only Encrypted Noise
+
+ No keys. No plaintext. No patterns. No metadata leaks. Every adversary — past, present, or future — sees only random bytes indistinguishable from noise.
+
+
+
-
-
-
-
Property
-
Description
-
-
-
-
-
Perfect Secrecy
-
Ciphertext reveals no information about plaintext without the pad
-
-
-
Forward Secrecy
-
Compromise after message sent cannot reveal that message's content
-
-
-
Future Secrecy
-
No computational advances can break past encrypted messages
-
-
-
Pad Non-Reuse
-
Core library enforces strict single-use semantics for all pad bytes
-
-
-
Integrity Detection
-
Frame checksums detect accidental corruption during transfer
-
-
-
Human Verification
-
Mnemonic checksums allow users to verify ceremony success verbally
-
-
-
-
+
+
+
Security Guarantees
-
-
-
3. Non-Guarantees
+
+ When used correctly, ASH provides the following security properties:
+
-
- ASH explicitly does not protect against the following threats. These
- limitations are intentional design decisions, not implementation flaws.
-
+
+
+
+
+
Property
+
Description
+
+
+
+
+
Perfect Secrecy
+
Ciphertext reveals no information about plaintext without the pad
+
+
+
Forward Secrecy
+
Compromise after message sent cannot reveal that message's content
+
+
+
Future Secrecy
+
No computational advances can break past encrypted messages
+
+
+
Pad Non-Reuse
+
Core library enforces strict single-use semantics for all pad bytes
+
+
+
Integrity Detection
+
Frame checksums detect accidental corruption during transfer
+
+
+
Human Verification
+
Mnemonic checksums allow users to verify ceremony success verbally
+
+
+
+
+
-
3.1 Compromised Device
-
- If the user's device is compromised by malware, the operating system, or
- hardware-level attacks, ASH cannot provide protection. A compromised device
- can read messages before encryption or after decryption, capture screen
- contents, or exfiltrate the pad.
-
+
+
+
What ASH Does NOT Protect Against
-
3.2 Malicious Participant
-
- If the person you are communicating with intends to betray you, they can
- screenshot messages, record conversations, or share content with third
- parties. ASH requires trust between participants.
-
+
+ These limitations are intentional design decisions, not implementation flaws.
+
-
3.3 Visual Observation
-
- If an adversary can observe the QR codes during the ceremony (through
- cameras, mirrors, or direct observation), they can capture the pad.
- The ceremony must be performed in a location where visual observation
- is not possible.
-
+
+
+
+
+
+
+
+
Compromised Device
+
+
Malware, OS exploits, keyloggers, hardware implants
+
A compromised device can read messages before encryption or after decryption.
+
-
3.4 Forensic Analysis
-
- ASH performs best-effort memory wiping using volatile writes, but cannot
- guarantee forensic irrecoverability. Physical device seizure may allow
- recovery of data through advanced forensic techniques.
-
+
+
+
+
+
+
+
Malicious Partner
+
+
Screenshots, betrayal, recording, sharing content
+
ASH requires trust between participants. Your partner can always betray you.
+
-
3.5 Traffic Analysis
-
- ASH does not provide anonymity or hide network metadata. Adversaries can
- determine that ASH is being used, observe communication timing patterns,
- and correlate activity between users based on timing.
-
+
+
+
+
+
+
+
Visual Observer
+
+
Cameras, shoulder surfing, mirrors, direct observation
+
QR codes during ceremony can be captured. Perform ceremony privately.
+
-
3.6 Coercion
-
- While the pad exists, users can be compelled to decrypt messages. ASH
- provides no deniability features. The burn function destroys data but
- cannot be performed if the device is seized.
-
Never sees plaintext or key material; assumed compromised
-
-
-
Network
-
Untrusted
-
Assumed hostile; all traffic is OTP-encrypted
-
-
-
Operating System
-
Trusted
-
Must trust OS for entropy, memory protection, secure storage
-
-
-
Conversation Partner
-
User Decision
-
ASH cannot protect against malicious participants
-
-
-
-
+
+
+ Important: These are fundamental limitations of any messaging system, not flaws in ASH. No technology can protect against a compromised device or a betraying partner. ASH is transparent about these boundaries.
+
+
+
-
-
-
5. User Responsibilities
+
+
+
Trust Boundaries
-
- Security in ASH is a shared responsibility. Users must:
-
+
+ ASH defines explicit trust levels for each component:
+
+
+
+
+
+
+
Component
+
Trust Level
+
Rationale
+
+
+
+
+
Core Library
+
Trusted
+
Cryptographic authority; small, auditable, zero dependencies
Never sees plaintext or key material; assumed compromised
+
+
+
Network
+
Untrusted
+
Assumed hostile; all traffic is OTP-encrypted
+
+
+
Operating System
+
Trusted
+
Must trust OS for entropy, memory protection, secure storage
+
+
+
Partner
+
User Decision
+
ASH cannot protect against malicious participants
+
+
+
+
+
-
-
- Perform the ceremony carefully. Do not rush. Scan all
- frames. Verify the mnemonic checksum verbally with your partner.
-
-
- Choose a private location. The ceremony must be performed
- where visual observation is not possible—no cameras, mirrors, or observers.
-
-
- Trust your conversation partner. ASH cannot prevent
- screenshots or betrayal. Only communicate with people you trust.
-
-
- Maintain device security. Keep your device updated,
- avoid installing untrusted software, and use device encryption.
-
-
- Understand the limitations. Read this document. Know
- what ASH protects against and what it does not.
-
-
-
+
+
+
User Responsibilities
-
-
-
6. Implementation Notes
+
+ Security in ASH is a shared responsibility. You must:
+
-
6.1 Entropy Sources
-
- Pad generation combines OS-provided cryptographic randomness with user
- gesture entropy. This defense-in-depth approach ensures that compromise
- of either source alone does not compromise pad randomness.
-
+
+
+ 1
+
+
Perform the ceremony carefully
+
Do not rush. Scan all frames. Verify the mnemonic checksum verbally with your partner.
+
+
+
+ 2
+
+
Choose a private location
+
The ceremony must be performed where visual observation is not possible — no cameras, mirrors, or observers.
+
+
+
+ 3
+
+
Trust your conversation partner
+
ASH cannot prevent screenshots or betrayal. Only communicate with people you trust.
+
+
+
+ 4
+
+
Maintain device security
+
Keep your device updated, avoid installing untrusted software, and use device encryption.
+
+
+
+ 5
+
+
Understand the limitations
+
Read this document. Know what ASH protects against and what it does not.
+
+
+
+
-
6.2 Memory Protection
-
- Sensitive data (pads, plaintext) is zeroed after use using volatile writes
- that prevent compiler optimization from removing the wiping operations.
- However, this does not guarantee forensic irrecoverability.
-
+
+
+
Implementation Notes
-
6.3 Supply Chain
-
- The core library has zero external dependencies to minimize supply chain
- attack surface. All cryptographic primitives are implemented directly:
- CRC-32, XOR encryption, and secure zeroing.
-
-
+
+
+
Entropy Sources
+
+ Pad generation combines OS-provided cryptographic randomness with user gesture entropy. Defense-in-depth ensures compromise of either source alone does not compromise randomness.
+
+
+
+
Memory Protection
+
+ Sensitive data is zeroed after use using volatile writes that prevent compiler optimization from removing wiping operations. Does not guarantee forensic irrecoverability.
+
+
+
+
Supply Chain
+
+ The core library has zero external dependencies to minimize supply chain attack surface. All cryptographic primitives are implemented directly.
+
+
+
+
-
-
-
- For security-critical deployments, conduct independent security audits
- of the implementation. This document describes design intent; actual
- security depends on correct implementation.
-
+
+
+
+ For security-critical deployments, conduct independent security audits. For technical details, see Whitepaper. For ethical considerations, see Ethics.
+
+ A comprehensive technical overview of the ASH secure messaging protocol, including architecture, ceremony specification, and frame format.
+
+
+
+
+
+
+
+
+
+
+
+
+
Protocol Overview
+
+
+
One-Time Pad Encryption
+
+ ASH uses the One-Time Pad (OTP) cipher, the only encryption method proven to provide information-theoretic security. Unlike computational security (used by AES, RSA, and modern cryptography), OTP security does not depend on mathematical assumptions or computational hardness.
+
+
+ The encryption is simple: each message byte is XOR'd with a corresponding key byte that is:
+
+
+
Truly random (from entropy sources)
+
As long as the message
+
Never reused (consumed after use)
+
Known only to the two parties
+
+
+
+{`Plaintext: H E L L O (message bytes)
+ ⊕ ⊕ ⊕ ⊕ ⊕ (XOR operation)
+Key: 7 K 2 X 9 (random key bytes)
+ = = = = =
+Ciphertext: ? ? ? ? ? (encrypted bytes)`}
+
+
+
+
+
Shannon's Perfect Secrecy
+
+ In 1949, Claude Shannon mathematically proved that OTP provides "perfect secrecy": the ciphertext reveals absolutely nothing about the plaintext to an attacker without the key.
+
+
+
+
+ Formal definition: A cipher has perfect secrecy if for all plaintexts M and ciphertexts C: P(M|C) = P(M). The probability of any plaintext given the ciphertext equals its prior probability.
+
+
+
+
+ This means that without the key, every possible plaintext is equally likely. "HELLO" could decrypt to "WORLD", "PIZZA", or any other 5-letter combination. No amount of computation—not even quantum computers—can determine the original message.
+
+
+
+
+
+
+
System Architecture
+
+
+ ASH consists of four primary subsystems with explicitly defined trust boundaries. Security emerges from clear component separation and minimal infrastructure trust.
+
+ The core is the cryptographic and procedural authority of ASH. All security-sensitive behavior is defined here, and all other components must treat it as authoritative.
+
+
+
+
+ Core Responsibilities
+
+
+
• One-Time Pad creation and management
+
• Strict pad single-use semantics enforcement
+
• Bidirectional pad consumption (Initiator/Responder)
+ ash-core must never: access the network, perform I/O, access OS randomness directly, contain platform-specific code, store data, include UI logic, or log sensitive data.
+
+
+
+
+
+
Mobile Applications
+
+ The iOS application (Android planned) is a presentation and orchestration layer. It invokes core functionality via UniFFI-generated Swift bindings and manages the user interface.
+
+
+ Mobile apps must never: reimplement cryptographic logic, alter OTP behavior, bypass the shared core, invent alternate checksums, persist decrypted messages, or perform silent background actions.
+
+
+
+
+
Backend Relay
+
+ The backend is a stateless RAM-only relay. It is intentionally simple and considered untrusted. Messages are held only in memory until ACK or TTL expiry.
+
+ Backend must never: persist messages to disk, decrypt messages, inspect payload contents, identify users, store data long-term, or implement business logic.
+
+
+
+
+
+
+
Ceremony Protocol
+
+
+ The ceremony establishes a shared One-Time Pad between two devices. It is designed to be offline, explicit, human-verifiable, and atomic.
+
+
+
+
Ceremony Flow
+
+
+
+
+
+ 1
+
+
Pad Size Selection
+
Sender selects pad size via slider, determining message capacity and ceremony duration.
+
+
+
+
+
+ 2
+
+
Entropy Collection
+
OS randomness mixed with required gesture input. User draws patterns while entropy accumulates visually.
+
+
+
+
+
+ 3
+
+
QR Transfer
+
Sender displays QR codes sequentially. Receiver scans each frame, validates CRC, and acknowledges.
+
+
+
+
+
+ 4
+
+
Mnemonic Verification
+
Both devices display 6-word checksum. Users verbally confirm match to detect tampering.
+
+
+
+
+
+ 5
+
+
Activation
+
Tokens derived from pad. Conversation becomes active. Messaging available.
+
+
+
+
+
+
+
+
+
Mnemonic Verification
+
+ The mnemonic checksum allows human verification that both devices have identical pads.
+
+
+
+
+
+
+
Property
+
Value
+
+
+
+
Wordlist size
512 words (custom, not BIP-39)
+
Bits per word
9 bits (512 = 2^9)
+
Word count
6 words
+
Verification entropy
54 bits
+
Word format
3-7 characters, lowercase ASCII
+
+
+
+
+
+ Words are optimized for verbal clarity: distinct pronunciation, no homophones, minimal confusion between similar words, and cross-language usability.
+
+
+
+
+
Pad Size Options
+
+
+
+
+
+
Size
+
Bytes
+
Capacity
+
Frames
+
Transfer
+
+
+
+
Tiny (32 KB)
32,768
~25 messages
~37
30-45 sec
+
Small (64 KB)
65,536
~50 messages
~74
1-2 min
+
Medium (256 KB)
262,144
~200 messages
~295
~5 min
+
Large (512 KB)
524,288
~400 messages
~590
~10 min
+
Huge (1 MB)
1,048,576
~800 messages
~1179
~20 min
+
+
+
+
+
+
+
+
+
Frame Format Specification
+
+
+ Frames chunk large pad data into scannable QR codes, provide integrity verification per chunk, and enable ordered reconstruction.
+
+ Unlike the QR frame format (used during ceremony), encrypted messages use a minimal structure. The goal is simplicity: plaintext XOR'd with pad bytes produces ciphertext that is sent to the relay.
+
+
+
+
Message Structure
+
+
+ Each message consists of plaintext encrypted with OTP and transmitted as an opaque blob. There is no envelope, header, or framing around individual messages.
+
+ Design rationale: No message envelope or metadata is included in the ciphertext itself. Message length equals ciphertext length equals pad bytes consumed. The relay sees only opaque bytes.
+
+
+
+
+
+
Bidirectional Pad Consumption
+
+
+ ASH uses a bidirectional consumption model to enable independent messaging by both parties without coordination or collision.
+
• Initiator (ceremony starter): Consumes bytes from index 0 forward
+
• Responder (ceremony receiver): Consumes bytes from the end backward
+
• No overlap: The two fronts never collide (pad exhausted when they meet)
+
• Independent: Either party can send without waiting for the other
+
• Asymmetric: Alice can use 20%, Bob can use 80% (or any split)
+
+
+
+
Forward Secrecy
+
+ After encryption, the used pad bytes are securely zeroed. Even if an attacker later compromises the device, they cannot decrypt messages encrypted with already-destroyed key material.
+
+
+
+
+
Message Types
+
+
+ ASH v1 supports two message types. Both are encrypted identically — the type is determined by content structure after decryption.
+
+
+
+
+
+
+
Type
+
Format
+
Size
+
+
+
+
+
Text
+
UTF-8 string
+
1 byte per character (ASCII) or more (Unicode)
+
+
+
Location
+
lat,lng (6 decimal places)
+
~25 bytes (e.g., "37.774929,-122.419418")
+
+
+
+
+
+
+
+ No media support: Photos and videos would exhaust pad capacity quickly. ASH intentionally supports only text and one-shot location sharing. This is a security feature, not a limitation.
+