Encryption, under scrutiny.
A Rust cryptography research project. The ambition is to beat the best. The evidence isn't there yet.
Test bench
Loading Rust engine...Work with sample text in this page. Encryption and decryption run locally in WebAssembly. No data upload, analytics, or saved keys.
Output
No operation yet.
Maximum plaintext: 1 MiB. The envelope includes its construction, nonce and authentication tag. A wrong key or changed envelope must fail.
First results
R1 does not beat either baseline.
First native release-build run, 1 MiB messages, 12 operations per construction. Throughput includes allocation and the envelope. These are a single machine's observations, not a universal ranking.
| Construction | Encrypt MiB/s | Decrypt MiB/s | Overhead |
|---|---|---|---|
| Obsidian R1 | 108.4 | 111.0 | 64 B |
| XChaCha20-Poly1305 | 1,010.1 | 1,136.0 | 48 B |
| AES-256-GCM | 1,041.3 | 1,068.3 | 36 B |
All use 32-byte master keys. Overhead includes the 8-byte version/mode header. Benchmarks do not measure cryptographic strength. Raw measurements · Environment
Research, not a claim
What R1 tests
Can a simple hash-based, authenticated construction be a useful baseline for further work? R1 separates its stream and authentication keys with HKDF-SHA-256, generates counter blocks with HMAC-SHA-256, and authenticates before releasing plaintext.
The first result is negative: more overhead and lower throughput. That stays in the record.
What a proof would need
Precise privacy and integrity games, explicit primitive assumptions, quantitative bounds, composition analysis and independent scrutiny. We have proof obligations, not a finished proof.
Known ways it fails
Reuse a key and nonce and the stream repeats. The attack bench demonstrates plaintext recovery from that mistake. Raw APIs cannot enforce fresh nonces. The browser generates a new nonce per encryption.
It does not hide length, prevent replay, establish keys, sign messages, or protect a compromised browser. Memory erasure is not guaranteed.
Not the same job
AES encrypts data. RSA supplies public-key operations. ML-KEM establishes shared keys, while ML-DSA and SLH-DSA sign. A symmetric envelope cannot replace all of them or win a meaningful single leaderboard.
Mathematically uncrackable?
Perfect secrecy is possible under strict one-time-pad assumptions: a uniformly random, independently shared key as long as the message, never reused. It doesn't provide authentication or solve key delivery. A short reusable key cannot offer perfect secrecy for arbitrary longer messages. R1 makes no unconditional, quantum-proof, or best-on-earth claim.
Full design and threat model · Attack record