I'm not sure this really hits E2EE. E2EE is a claim about who cannot read your mail, so the test is whether confidentiality survives a hostile operator. This model fails that test twice, and the choice of PGP decides how bad the second failure gets.
Take an operator that ships bad code first. The crypto runs in JavaScript that AurionMail serves on every page load, and nothing pins that bundle: no reproducible build, no signature the browser enforces, no way for a user to verify what ran. One build that posts the master passphrase to a host they control ends it. Password strength, the 5-minute TTL, and the non-extractable CryptoKey all stop mattering. Every guarantee in the document becomes a promise about operator behaviour, and E2EE exists to remove those promises. Signed reproducible clients fix this, or published bundle hashes in a transparency log. Their security model never mentions its own delivery channel.
Ignoring that/assuming an honest build pipeline--what does a breach, an insider, or a subpoena yields later. The server holds the wrapped OpenPGP private key, the 16-byte master salt (cross-device unlock needs it), and Argon2id(password, "auth_salt_${username}") from every login. That last value verifies the same password protecting the vault, so you can grind offline at Argon2id cost, derive the master key, unwrap the PGP key, and read the mail. auth_salt_${username} is public and known before any breach, so an attacker can precompute against a named target. A random per-user salt served at login removes that discount. Proton and Bitwarden share the general ceiling, so what follows is what makes this design worse.
In addition, PGP has no forward secrecy. Combine that with a server-side mail archive and a server-side copy of the long-term private key. One password recovery at any future point then decrypts the entire history in one pass. A long-term key is only as strong as the weakest security practice across its whole lifetime, and an attacker who eventually wins reads the full back catalogue. Remote backups of the long-term key are a pattern to avoid here, but AurionMail ships that backup as a sync feature. The document reasons carefully about a 5-minute TTL on a transport blob while the real exposure window is the account's entire lifetime, applied backwards.
Rotation makes it stickier. The same post argues that people keep keys they suspect are compromised because rotating costs too much. Here the master password derives both the PGP wrapping key and the CryptPad seed, so a password change orphans CryptPad documents, and replacing the PGP key means re-establishing it with every correspondent. Two coupled rotation costs, and the document specifies neither procedure.
Coverage is the other limit. PGP over SMTP leaves envelope recipients and timestamps in clear, and it only protects mail where the other party also runs PGP. Most folks see very few encrypted emails a year, and correspondents generally resend in plaintext given any excuse. The other end decides your coverage. The security model also never says how a user authenticates a correspondent's public key, and encrypting to an attacker's key defeats everything upstream of it. Web of trust does not close that gap in practice.
Two parts of the design are correct. The cross-origin handoff keeps the seed off the network, so the server holds ciphertext it cannot open, and burn-on-read with a short TTL layers sensibly on top. One Argon2id pass feeding domain-separated HKDF labels is standard, and separate salts for auth and for the master key keep the login hash from being the vault key.
From my POV, this is client-side encryption with a trusted operator, built on a key model that competent advocates were publicly abandoning ten years ago. That property is real and it beats server-side encryption, and it requires trusting their build pipeline, their hosting, and their users' passwords. "Zero-knowledge" claims none of that trust is needed, but their security model doesn't support this claim.
Thanks a lot for taking the time to read the security model so thoroughly and for providing such a detailed critique. I didn't think someone would do it ! This is extremely valuable feedback.
A few thoughts on your specific points:
- You are right about the web threat model. Serving the crypto bundle over the web means trusting the server not to serve malicious JS at load time. Moving towards reproducible builds, bundle hashing, or a dedicated browser extension is definitely the long-term path to remove operator trust on code delivery.
- For the `auth_salt_${username}` salt, this is a choice I made at the beginning of the project, an error, and it should be replaced soon. However, this is only used for authentication and not encryption.
- Changing the master password does not orphan CryptPad documents. The master password is solely used client-side to derive the wrapping key that encrypts the underlying persistent secrets (the PGP private key and the CryptPad account pass).
When changing the password:
1. The persistent secrets are unwrapped in RAM using the old derived key.
2. They are re-wrapped using the new key derived from the new master password.
3. CryptPad's native account key update process is triggered with old and new secret.
Framing AurionMail as "client-side encryption with a trusted operator" rather than absolute ZK is a fair and accurate classification of the current web-based threat model. I'll update the documentation and security spec to clarify these trust assumptions explicitly.
I found this to be a really informative piece about how people at the forefront of their field (in this case, AppSec) can move themselves farther with LLMs, as well as the limits to be dealt with and handled in that process.
The tl;dr on why IO is important is you can just use (effectively) one program, but stuff different secrets inside them with a guarantee that no one can pull those secrets back out.
Cryptographers have proven that it's possible to use this as a primitive from which you can rebuild the rest of common cryptographic primitives (public encryption, symmetric encryption, etc). So--if it's possible to put this together it'll be a novel construction for every cryptographic primitive that also dodges some of the problems with key distribution and negotiation.
It's interesting to see such ongoing strong jobs data in the face of unprecedentedly negative sentiment[1]. Not only do the numbers fail to look as bad as the sentiment, the numbers are actually fantastic and (AFAICT) fully uncorrelated with sentiment.
I've been thinking that this is basically a result of people being overexposed to aspirational lifestyle marketing influencers--even though they're doing better than ever, they're more aware than ever that others are doing even massively better. Since it's influencer marketing, they're seeing people do better in specific ways that appeal to them instead of just being passively aware that others are richer.
I'm surprised y'all stopped at the personal finance layer. I've been thinking for awhile that LLMs would be really effective as personal financial advisers, and this kind of hookup (plus I guess another one for investment accounts?) seems like all that's needed to bootstrap reasoning.
Yup! Actually starting to experiment with that now.
Just this morning, we stood up a demo email agent (basically, email back and forth with Claude with our MCP server connected, providing the data) and it's strangely comforting to chat with it. There's something about the medium of email and how it just works because that's where you're already used to talking with your financial advisor.
There's a lot of nuance in how it's built though, and everyone has different preferences, so to start with the focus is really on building an agent-friendly MCP.
I’ve thought the same. Because the main thing a financial advisor does is have the knowledge of different financial instruments and pair it with your situation right?
An LLM would do that extremely well but can also do it more often. not once a year appointments. You could have active portfolio management for a negligible fee.
Who accepts the liability when the LLM does its typical occasional massive judgement fuck up?
Asking that because even the very best, commercially available, state of the art LLMs (presently Claude Opus 4.7 (1M) with Max effort enabled) still occasionally fucks up its decisions and judgement in significant ways.
So, it's kind of horrifying to me that people would consider this for actually potentially life-impacting ways. Especially as it sounds like the consideration is to advise people in area's they don't themselves have the skill and knowledge to catch bad advice on. :(
Yeah, investing over time in such a way to beat the S&P is actually incredibly challenging (having tried it myself). I’m very skeptical an LLM can do better than that unless it has a very large, expensive firehose of data.
It may be that more mundane analysis ends up being the most useful. For example — for years, we had some money in a money market fund earning basically no interest. It just wasn’t on the radar.
Had even a not very smart LLM nudged us to put the money into a HYSA earlier, we would have made thousands per year in interest.
My wife also recently used our tool to do some simple investing optimization that’s going to save us a few thousand per year on taxes.
Thing like this aren’t sexy but do have value, and don’t take GPT Pro.
"You are absolutely right! This is a very deep, professional level insight. Yes, I have blown up your account but we can try more of my investment ideas. What would you like to do next?" /s
Would you be comfortable using this same logic to invest most of your net worth in lottery tickets/betting on black in a casino? If not, I'd be curious to hear what is different in that for you.
> Would you be comfortable using this same logic to invest most of your net worth in lottery tickets/betting on black in a casino?
I wouldn't "invest" in lottery tickets because for these p is far too small (exception: if I found a loophole in the system of the lottery, which has been found for some lotteries). For casinos, there is additionally the very important aspect that the casino will scam you (if you start winning money (for example by having found some clever strategy that gives you an advantage), the security will escort you out of the building and ban you from entering the casino again).
So, to give an explanation of the differences:
- Because "the typical run" for such an investment will be loosing, you should never invest your whole net worth (or a significant fraction thereof) into such an investment. The advice that I personally often give is to use index funds or stock investments for generating the money for investments that are much more risky, but have huge possible payouts.
- You should only do such an "early investment" if you have a significant information advantage over the average person. Such an advantage is plausible, for example, if you are deeply interested in technology topics
- Lottery tickets have an insanely small p (as defined in my comment). You only do "early investments" into topics where the p is still small, but not absurdly bad. The difference is that for lottery tickets the p is basically well-known. On the other hand, for "early investments", people can only estimate the p. Because of your information advantage from the previous point, you can estimate the p much better than other people, which gains you a strong advantage in picking the right "early investments" to choose.
But be aware that this is a strategy for risk-affine people. If you aren't, you better stay, for example, with index funds.
If you’re paying a fair price for the risk, sure. Most of the examples you gave seemed to be in deep speculative territory to the point that they don’t very much resemble anything economic.
My FAANG employer launched a service ~6 months ago that today seems millions of DAUs. This service was 100% vibe coded. This service was created 20x faster than the median launch, and had notably fewer issues than the median launch. If AI stopped improving today, it would be a technological leap equivalent to a new high-level language paradigm for us.
To me this is completely unrelated to the quality of the PRNG, because security is explicitly a non-goal of the design. A general-purpose non-cryptographically secure PRNG is evaluated primarily on speed and uniformity of output. Any other qualities can certainly be interesting, but they're orthogonal to (how I would evaluate) quality.
Right: put differently, why would you bother to select among the insecure RNGs an RNG whose "seed" was "harder" to recover? What beneficial property would that provide your system?
CSPRNGs have all of the desirable properties for the output.
All else being equal, I don't think it is possible for a trivially reversible generator to have better statistical properties than a generator whose output behaves more like a CSPRNG.
It can definitely be good enough and or faster, though.
Right, I think defaulting to a CSPRNG is a pretty sane decision, and you'd know if you had need of a non-CSPRNG RNG. But what does that say about the choice between PCG and xorshiro?
Defaulting to a CSPRNG pre-seeded with system randomness is not a bad choice per se(especially given many users don't know they need one) but current ones are much slower than the RNGs we are discussing.
If you're going to provide a non-CS one for general simulation purposes, you probably want the one that is the closest to indistinguishable from random data as you can without compromising performance, though.
Some people will have more than enough with a traditional LCG(MC isn't even using RNGs anymore) but others may be using more of the output in semantically relevant ways where it won't work.
If Xoshiro's state can be trivially recovered from a short span of the output, there is a local bias right there that PractRand lets through but that your application could accidentally uncover.
The choice is: Are the performance gains enough to justify that risk?
Why does it matter if the state can be trivially recovered? What does that have to do with the applications in which these generators are actually used? If the word "risk" applies to your situation, you can't use either xorshiro or PCG.
This is too deep to reply but if a bit is dependent on the value of a bit a couple bytes back then it is not acting randomly.
It's not about security.
I hope you can agree that if every time there is a treasure chest to the left of a door, a pink rabbit spawns on the top left of the room, that's not acting very random-like.
I'm not taking a position on the perceived added value of PCG over Xoshiro.
The property you're talking about (next bit unpredictability) is important for a CSPRNG, but it doesn't matter at all for a PRNG. A PRNG just needs to be fast and have a uniform output. LCGs, for instance, do not have next bit unpredictability and are a perfectly fine class of PRNG.
The paper that triggered this thread "breaking" PCG sees it as potentially in the same class of issues as using RANDU.
> our results […] do mean that [PCG']s output has detectable properties. Whether these properties may affect the result of Monte-Carlo numerical simulations is another matter entirely.
Again this is on PCG which required a breaking effort.
The short version of Xorshift as originally presented by Marsaglia outputting its whole state for example is bound to have behaviors like my room-generation example emerging fairly easily. Particularly, with low hamming-weight states.
I doubt Xoshiro's output is that bad but if presented as trivial to recover vs PCG, that to me indicates potential issues when using the output for simulation.
Take an operator that ships bad code first. The crypto runs in JavaScript that AurionMail serves on every page load, and nothing pins that bundle: no reproducible build, no signature the browser enforces, no way for a user to verify what ran. One build that posts the master passphrase to a host they control ends it. Password strength, the 5-minute TTL, and the non-extractable CryptoKey all stop mattering. Every guarantee in the document becomes a promise about operator behaviour, and E2EE exists to remove those promises. Signed reproducible clients fix this, or published bundle hashes in a transparency log. Their security model never mentions its own delivery channel.
Ignoring that/assuming an honest build pipeline--what does a breach, an insider, or a subpoena yields later. The server holds the wrapped OpenPGP private key, the 16-byte master salt (cross-device unlock needs it), and Argon2id(password, "auth_salt_${username}") from every login. That last value verifies the same password protecting the vault, so you can grind offline at Argon2id cost, derive the master key, unwrap the PGP key, and read the mail. auth_salt_${username} is public and known before any breach, so an attacker can precompute against a named target. A random per-user salt served at login removes that discount. Proton and Bitwarden share the general ceiling, so what follows is what makes this design worse.
In addition, PGP has no forward secrecy. Combine that with a server-side mail archive and a server-side copy of the long-term private key. One password recovery at any future point then decrypts the entire history in one pass. A long-term key is only as strong as the weakest security practice across its whole lifetime, and an attacker who eventually wins reads the full back catalogue. Remote backups of the long-term key are a pattern to avoid here, but AurionMail ships that backup as a sync feature. The document reasons carefully about a 5-minute TTL on a transport blob while the real exposure window is the account's entire lifetime, applied backwards.
Rotation makes it stickier. The same post argues that people keep keys they suspect are compromised because rotating costs too much. Here the master password derives both the PGP wrapping key and the CryptPad seed, so a password change orphans CryptPad documents, and replacing the PGP key means re-establishing it with every correspondent. Two coupled rotation costs, and the document specifies neither procedure.
Coverage is the other limit. PGP over SMTP leaves envelope recipients and timestamps in clear, and it only protects mail where the other party also runs PGP. Most folks see very few encrypted emails a year, and correspondents generally resend in plaintext given any excuse. The other end decides your coverage. The security model also never says how a user authenticates a correspondent's public key, and encrypting to an attacker's key defeats everything upstream of it. Web of trust does not close that gap in practice.
Two parts of the design are correct. The cross-origin handoff keeps the seed off the network, so the server holds ciphertext it cannot open, and burn-on-read with a short TTL layers sensibly on top. One Argon2id pass feeding domain-separated HKDF labels is standard, and separate salts for auth and for the master key keep the login hash from being the vault key.
From my POV, this is client-side encryption with a trusted operator, built on a key model that competent advocates were publicly abandoning ten years ago. That property is real and it beats server-side encryption, and it requires trusting their build pipeline, their hosting, and their users' passwords. "Zero-knowledge" claims none of that trust is needed, but their security model doesn't support this claim.