xero
https://github.com/xero/leviathan-crypto
Zero-dependency WebAssembly cryptography library for TypeScript: Serpent-256, XChaCha20-Poly1305, SHA-2/3, HMAC, HKDF, and Fortuna CSPRNG, with a strictly typed API built on vector-verified primitives
#wasm #crypto #typescript #javascript #cryptography
Mar 18 at 3:26amWeb
Show threadxero4d ago
Serpent-256, the most conservative AES finalist, employs 32 rounds and a maximum security margin, built to withstand future cryptanalytic advancements. Paired with the streamlined brilliance of ChaCha20-Poly1305, and complemented by SHA-2 and SHA-3. Two design philosophies, four cryptographic primitives, integrated into one coherent API.
Show threadRobert Vitonsky4d ago

@xero it sounds very nice, i will look at the code.

I have couple questions.

1. How to verify an encryption cipher implementation? Author may miss something, or intentionally leave a backdoor. It may happens with the code and with the spec too. So how to make sure the cipher is canonical?

2. Why there are no TwoFish? 😀 That's enough popular algorithm, that is slower with no hardware acceleration, but it is still a popular alternative to AES

Show threadxero4d ago

@vitonsky thanx. The project security policy explicitly calls out most of these: https://github.com/xero/leviathan-crypto/blob/main/SECURITY.md

but to answer you directly, twofish is a legacy cipher. it's not deprecated, but it's been replaced with more modern alternatives. XChaCha20-Poly1305 is better in every measurable respect.

about correctness , known answer test (KAT) vectors. The spec or RFC is almost always published with known correct vectors. some of them not just input output but at different rounds of the cipher. vector corpus: https://github.com/xero/leviathan-crypto/tree/main/test/vectors

next, we build unit tests using the kat vectors. the known correct answers work as implementation guardrails. you can read about the projects testing methodology here: https://github.com/xero/leviathan-crypto/blob/main/docs/test-suite.md

finally, I'm doing line by line implementation analysis of the code versus the RFC or spec:
https://github.com/xero/leviathan-crypto/blob/main/docs/serpent_audit.md

this library is for me. I made it for me. I need it for projects and why not open source it. The last thing I want in any project I make and put my name on is a back door.

leviathan-crypto/SECURITY.md at main · xero/leviathan-crypto

Zero-dependency WebAssembly cryptography library for TypeScript: Serpent-256, XChaCha20-Poly1305, SHA-2/3, HMAC, HKDF, and Fortuna CSPRNG, with a strictly typed API built on vector-verified primiti...

GitHub
Show threadxero4d ago
@vitonsky One more note on correctness. I actually ship documentation and an agent's config file. library consumers who use code assistance Will immediately have the libraries correct implementation and architecture documentation explained to the agent up front.
Show threadRobert Vitonsky4d ago

@xero when you implement the specific cipher, how you can make sure there are no backdoors on a spec level?

I mean you looking for spec on the internet, right? Is the authority of a site the only thing that makes you beleive the spec have not been changed by a law enforcement agencies?

As a programmers with no a math PhD, how we can verify the algorithm with zero trust policy in the world where everyone (even spec and ChatGPT) can lying us?

Show threadxero4d ago

@vitonsky you don't trust the spec. You trust the math, the vectors, and the community.

Specs are published in multiple places simultaneously. FIPS 202 (SHA-3) lives on NIST's site, on archive.org, in academic papers, in dozens of independent implementations across languages. Silently modifying all of them without anyone noticing is not a realistic attack. The threat model for "law enforcement secretly changed the spec" requires a global conspiracy across competing nations, universities, and open source communities, including China, Russia, and the EU, who all have independent implementations and strong incentives to find any NSA-introduced weakness.

Show threadxero4d ago

@vitonsky **Test vectors are the real measure.** For leviathan specifically, we don't just implement the algorithm, we verify our implementation produces byte-identical output to published Known Answer Test (KAT) vectors from independent sources: NIST, NESSIE (a European project), academic papers, and tools like OpenSSL and Python's hashlib running independently.

for example, if our SHA-256 produces the same 32 bytes as OpenSSL & hashlib for 10,000 different inputs, it doesn't matter where we got the spec from. the math is the math

Show threadxero4d ago

@vitonsky The most famous example of suspected backdoor — Dual_EC_DRBG — was found. Researchers noticed it had a suspicious constant and published the concern years before Snowden confirmed it. The community caught it through exactly this kind of scrutiny. Serpent (our primary cipher) got more first-place security votes than AES from the NIST panel — partly because its conservative design makes it easier to audit for exactly this kind of thing.

For algorithms with no known weaknesses after 20+ years of public cryptanalysis: at some point "sufficiently many smart people from adversarial countries have independently verified this" becomes a meaningful form of trust. Not infinite trust, but the same kind of trust you extend to arithmetic.

The honest limit: a math PhD is not required, but understanding why a construction is secure does require study. What you can do as a programmer without the PhD is verify test vectors from independent sources, use implementations that have been independently audited, and prefer older, more-analyzed algorithms over newer ones.

That's exactly what leviathan does. we chose Serpent partly because 25 years of cryptanalysis has failed to break it in any practical way.

The zero-trust version of this isn't "trust no spec", it's "verify outputs against independent implementations, prefer algorithms with long public track records, and read the audit trail."

Show threadxero4d ago

@vitonsky I appreciate your interest & honest questions.

please don't take my dissertation responses as anything more than just trying to fully answer your question.

I'm very open to suggestions, updated threat modeling, and other optimizations.

this is my first release but I've been working on this for months. first in pure typescript, then rewritten from specs in webassembly, and now kind of combining the projects together.

Show threadRobert Vitonsky4d ago

@xero I actually like your answers and I consider this discussion as a way to understand how we can trust in cryptography we use every day.

Let's say I want to add an alternative encryption cipher in my privacy focused app to let user choose the algorithm they trust.

As user I have no choice but only to blindly trust the encryption in apps. We all do that.

It is not trivial for me to understand how I can verify cryptography as a programmer.

Show threadRobert Vitonsky4d ago

@xero I see the point about a test vectors. That sounds interesting, but yields the same questions about the trust. Why we should trust to this vectors?

The backdoored spec may be invented to pass well known vectors. OpenSSL and others takes the spec from the internet too, and just write the code according to the spec.

Show threadRobert Vitonsky4d ago

@xero Is only an Occam's razor principle ensures the security?

I mean your point have sense, if we trying to not over-think, and believe a "global conspiracy" does not exist it becomes a simple puzzle - the vectors are a math proof of the spec version that is published on the internet, the world have consensus that this spec does work well in math terms.

What if we would believe the spec may had been changed globally, for example while a first publication?

Show threadxero4d ago
@vitonsky Occam's razor: this is kind of a misread of what vector verification does. KAT vectors aren't about assuming no conspiracy. They're about proving this implementation matches this specification. That's a mathematical claim, not a trust claim. The spec could be evil and the vectors would still prove implementation fidelity. Those are orthogonal.
Show threadxero4d ago

@vitonsky "What if the spec was compromised at publication?" this is the real and legitimate question, and it has real history. Dual EC DRBG is the canonical example: an NSA-backdoored PRNG that NIST standardized in 2006, which Snowden documents confirmed was intentionally weakened. The backdoor was in the constants, specific elliptic curve points that were "chosen" in ways that gave the NSA a shortcut.

This is exactly why Serpent's constant selection matters and why the library documents it. Serpent's S-boxes come from a published derivation procedure, they're not arbitrary. The nothing-up-my-sleeve numbers are verifiable. The AES competition process was public, with multiple independent teams. SHA-2/SHA-3 constants are derived from cube roots of primes, you can easily verify them yourself from scratch.

Show threadxero4d ago

@vitonsky The honest answer is: no cryptographic primitive is proof against a compromised spec. What you can do is prefer primitives where:

- The constant derivation is transparent and independently reproducible
- The design process was public with adversarial review
- The security margin is large enough to survive unknown weaknesses (hence Serpent's 32 rounds vs AES's 10–14)

The library's conservative primitive choices aren't paranoia theater, Serpent's security margin philosophy is directly a hedge against "what if AES has structural weakness we don't know about yet."

Show threadxero4d ago

@vitonsky specs are written and then voted on independently by organizations who decide if they're going to implement them or not. generally speaking I would hope most organizations would do targeted risk assessments on any mission critical technology they would be adding into their stack. a crypto library is definitely within that scope.

how deep you go in your own risk assessment is on you. as the consumer. you decide your own level of involvement.

that being said, in the serpent audit, I link my biclique attack research. I independently read every scholarly attack paper I could find. then both threat modeled and attempted to actively exploit these techniques against my own library. I was able to achieve a better results than the published paper, 10 years ago. but even with my advancements it's still in the realm of theoretical with how strong 32 rounds of serpent 256 s box math is.

Show threadxero4d ago

@vitonsky programming open source projects is a team effort. everyone has their own skills and expertise. I'm currently the only developer on this project, but I would love to have a greater team help analyze and verify work. part of the reason why I'm hyping it up here. looking for like-minded friends who want to get involved.

The idea is enough nerds all attack a spec when it first comes out. looking for holes. everyone wants to get the credit of eviscerating a brand new cryptographic primitive. that research feeds into what might happen to the spec in a new version, our decision whether we include it or not, and things like that. it's like herd mentality. you have to rely on other people to help validate. you. can't do it all yourself.

Show threadxero4d ago
@vitonsky I'm using the same logic principal as textual criticism for old books. multiple attestation. if you have multiple independent sources all saying the same thing that's correlative evidence. The opposite of that is also true. and both are important signals to watch.
Show threadxero4d ago
@vitonsky during my research and planning phase if I cannot find authoritative answers, EG there are multiple conflicting vectors for the same primitive, I probably would not implement that primitive because Id be unable to verify accuracy. full transparency, that is not come up though in anything I've done.
Show threadxero4d ago
@vitonsky That's the right mentality to have. That's why I have an insane amount of documentation written around this project. The wiki is focused in two ways. The typescript apis are for developers that don't have phds. as you said. The assembly docs are for the crypto nerds that really want to dig into the implementation itself. The typescript documentations have tons of examples, guardrails, explanations of why you need to do things, etc. I've tried to set consumers of my library up for a success as much as possible. since I'm a subject matter expert, in some respect, it's my obligation to hand hold users and help them implement cryptography correctly with my library. it's one of my design goals. The API surface itself is designed to stop footgun logic. and help make this stuff more straightforward.