Google Workspaces and Dropbox have an IL5-compliant offering, which means they attest that they will not do exactly this (and are audited on that). Not sure about iCloud and Notion.
Your NDAs prohibit emailing a colleague about the e.g. project, or discussing it in a Slack DM with the client, or tracking progress on it in JIRA? You have to do NDA’d work exclusively with local tools or end-to-end encryption? Those are some difficult NDAs!
We use inhouse on-premises email, issue tracking, and messaging. Depending on the project, external communication does require E2EE email. Development happens on local hardware and software unless required otherwise by the customer.
I’m pretty sure (even just based on the revenue of various SaaS products) that’s not typical, hence “most NDAs”. I’m also sure some require a SCIF, but that’s not most of them.
No this is still the level below needing a SCIF. The USG really tightened this stuff up in the 2010s and highly restricts what you can do with CUI. That's why there's a whole parallel FedRamp-compliant cloud ecosystem.
But in terms of how common it is, pretty much everybody in Fairfax County works in a company with rules like this; it's a big part of why the tech culture is so different than Austin or SFO.
Oh Lord yes. We have very specific communications channels we're allowed to use about any of our sensitive products, and that's only the unclassified stuff (classified is obviously its own, stricter, beast).
I would really like to look at the bug and whether we could have caught it with conventional testing, but it doesn't look like Apple actually disclosed it?
I just use the VS Code git integration with the jj colocated git repo. HEAD is @- and the changes in @ are considered working copy changes. It works for all I was using the VS Code integration for.
This will probably not help enough for asymmetric keys, and is unnecessary for symmetric keys. https://arxiv.org/abs/2603.28846 claims an attack runtime of a few minutes.
There are enough order-of-magnitude breakthroughs between today and scalable quantum error correction, that it makes no sense to try to to guess exactly the order of magnitude of the attacks that will be feasible.
Either you believe they won't happen, in which case you can keep using long-term ECDSA keys, or you believe they will happen, in which case they are likely to overshoot your rotation period.
The calculated DW cost of the quantum attack is 2^104 (with conservative/optimistic assumptions and ignoring the physical cost of a single logical gate), which is "much more realistic than a brute force attack" in the same sense that a 128-bit brute force attack is much more realistic than a 256-bit brute force attack.
None of those are remotely practical, even imagining quantum computers that become as fast (and small! and long-term coherent!) as classical computers.
Hashes are symmetric cryptography primitives, and it's even proper to talk about key sizes for e.g. HMAC and HKDF hash-based constructions, to which Grover's algorithm applies analogously to how it applies to cipher keys.
Assuming a member of the target audience sees the connection between HMAC and symmetric keys AFA usage, would you like them to be making leaps like this in their regular usage of cryptography? (I really couldn't tell you if an algorithm that involves being able to look into the box in the middle might not have characteristics that means part or all the primitives involved are less quantum safe than an algorithm that lacks that possibility yet I'd suspect I have a lot more experience than the average reader drawn in by the title.)
Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s
Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument against the NSA promoting mathematically broken cryptography, if anything.)
Timing side channels don't matter to ephemeral ML-KEM key exchanges, by the way. It's really hard to implement ML-KEM wrong. It's way easier to implement ECDH wrong, and remember that in this hypothetical you need to compare to P-256, not X25519, because US regulation compliance is the premise.
(I also think these days P-256 is fine, but that is a different argument.)
I genuinely do not understand how someone working in the capacity that you do, for things that matter universally for people, can contend that an organization who is intentionally engaging in NOBUS backdoors can be remotely trusted at all.
That is insanely irresponsible and genuinely concerning. I don't care if they have a magical ring that defies all laws of physics and assuredly prevents any adversary stealing the backdoor. If an organization is implementing _ANY_ backdoor, they are an adversary from a security perspective and their guidance should be treated as such.
The world just doesn’t work in such a binary way. Forming a mental model of an entity’s incentives, goals, capabilities, and dysfunctions will serve you much better than making two buckets for trusted parties and adversaries.
As you are someone building cryptographic libraries used by people all over the world, which includes those who might be seen as "enemies" by the organization in question, this is not a gradient — it's quite binary in nature.
Maybe your motives are benevolent, but you're arguing two things:
1) We can broadly trust the US government
2) We should adopt new encryption partly designed and funded by the US government, and get rid of the battle tested encryption that they seem not to be able to break
Forgive me for being somewhat suspicious of your motives here
> Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency
NSA still has the secret Suite A system for their most sensitive information. If they think that is better than the current public algorithms and their goal is to make telecommunications vendors to have better encryption, then why doesn't they publish those so telco could use it?
> Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument against the NSA promoting mathematically broken cryptography, if anything.)
The NSA weakened DES against brute-force attack by reducing the key size (while making it stronger against differential cryptanalysis, though).
The thing that sets this effort apart from DES and Clipper is that USG actually has skin in the game. Neither DES or Clipper were ever intended or approved to protect classified information.
These are algorithms that NSA will use in real systems to protect information up to the TOP SECRET codeword level through programs such as CNSA 2.0[1] and CsFC.
> Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s
I guess the NSA thinks they're the only one that can target such a side channel, unlike, say, a foreign government, which doesn't have access to the US Internet backbone, doesn't have as good mathematicians or programmers (in NSA opinion), etc.
> Timing side channels don't matter to ephemeral ML-KEM key exchanges, by the way. It's really hard to implement ML-KEM wrong. It's way easier to implement ECDH wrong, and remember that in this hypothetical you need to compare to P-256, not X25519, because US regulation compliance is the premise.
Except for KyberSlash (I was surprised when I looked at the bug's code, it's written very optimistically wrt what the compiler would produce...)
So do you think vendors will write good code within the deadlines between now and... 2029? I wouldn't bet my state secrets on that...
That's a timing side-channel, irrelevant to ephemeral key exchanges, and tbh if that's the worst that went wrong in a year and a half, I am very hopeful indeed.
> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys
It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.
My opinion changed on the timeline of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.
I don't think you said (or cited) what you think you said.
Leaving aside that you actually didn't cite a lattice attack paper, the "dual attack" on lattice cryptography is older than P-256 was when Curve25519 was adopted to replace it. It's a model attack, going all the way back to Regev. It is to MLKEM what algebraic attacks were (are?) to AES.
You know you're in trouble in these discussions when someone inevitably cites SIDH. SIDH has absolutely nothing to do with lattices; in fact, it has basically nothing to do with any other form of cryptography. It was a wildly novel approach that attracted lots of attention because it took a form that was pin-compatible with existing asymmetric encryption (unlike MLKEM, which provides only a KEM).
People who bring up SIDH in lattice discussions are counting on non-cryptography readers not to know that lattice cryptography is quite old and extremely well studied; it was a competitor to elliptic curves for the successor to RSA.
With that established: what exactly is the point you think those three links make in this discussion? What did you glean by reading those three papers?
He's obviously not saying that you can "trust blindly" any PQ algorithm out there, just that there are some that have appeared robust over many years of analysis.
He is assessing that the risk of seeing a quantum computer break dlog cryptography is stronger than the risk of having post quantum assumptions broken, in particular for lattices.
One can always debate but we have seen more post quantum assumptions break during the last 15 years than we have seen concrete progress in practical quantum factorisation (I'm not talking about the theory).
It's purely a matter of _potential_ issues. The research on lattice-based crypto is still young compared to EC/RSA. Side channels, hardware bugs, unexpected research breakthroughs all can happen.
And there are no downsides to adding regular classical encryption. The resulting secret will be at least as secure as the _most_ secure algorithm.
The overhead of additional signatures and keys is also not that large compared to regular ML-KEM secrets.
No it's not. This is the wrong argument. It's telling how many people trying to make a big stink out of non-hybrid PQC don't even get what the real argument is.
Perhaps you would care to enlighten us ignorant plebs rather than taunting us?
My understanding (obviously as a non expert) matches what cyberax wrote above. Is it not common wisdom that the pursuit of new and exciting crypto is an exercise filled with landmines? By that logic rushing to switch to the new shiny would appear to be extremely unwise.
I appreciate the points made in the article that the PQ algorithms aren't as new as they once were and that if you accept this new imminent deadline then ironing out the specification details for hybrid schemes might present the bigger downside between the two options.
I mean TBH I don't really get it. It seems like we (as a society or species or whatever) ought to be able to trivially toss a standard out the door that's just two other standards glued together. Do we really need a combinatoric explosion here? Shouldn't 1 (or maybe 2) concrete algorithm pairings be enough? But if the evidence at this point is to the contrary of our ability to do that then I get it. Sometimes our systems just aren't all that functional and we have to make the best of it.
"taunt" in the sense that you dangle some knowledge in front of people and make them beg, not "taunt" in the sense of "insult".
You said:
>"[...] don't even get what the real argument is."
and then refuse to explain what the "real" argument is. someone then asks for clarification and you say:
"It's definitely not [...]""
okay, cool! you are still refusing to explain what the "real" argument is. but at least we know one thing it isnt, i guess.
you haven't even addressed the "mistaken assertion". you just say "nah" and refuse to elaborate. which is fine, i guess. but holy moly is it ever frustrating to read some of your comment chains. it often appears that your sole goal in commenting is to try and dunk on people -- at least that is how many of your comments come across to me.
I was explicit about what the real argument isn't: the notion that lattice cryptography is under-studied compared to RSA/ECC.
I understand what your takeaway from this thread is, but my perspective is that the thread is a mix of people who actually work in this field and people who don't, both sides with equally strong opinions but not equally strong premises. The person I replied to literally followed up by saying they don't follow the space! Would you have assumed that from their preceding comment?
(Not to pick on them; acknowledging that limitation on their perspective was a stand-up move, and I appreciate it.)
You do "XYZ isn't the right argument, ABC is" on a thread like that, and the reply tends to be "well yeah that's what I meant, ABC is just a special case of XYZ". No thanks.
I'm not a professional cryptographer, but I _am_ really interested in opinions of experts in the field and I do have a lot of prior experience with crypto (the actual kind, not *coin). From my point of view, I just don't see what's the fuss is all about.
There's no shared understanding, just a snarky expert claiming (in effect) "I know better than all you simpletons but I'm not going to share". At best it's incredibly poor behavior. At worst it's the behavior of someone who doesn't actually have a defensible point to make.
As far as I know, the currently standardized lattice methods are not known to be vulnerable? And the biggest controversy seemed to be the push for inclusion of non-hybrid methods?
I'm not following crypto closely anymore, I stopped following the papers around 2014, right when learning-with-errors started becoming mainstream.
We can disagree on the tradeoff, but if you see no upside, you are missing the velocity cost of the specification work, the API design, and the implementation complexity. Plus the annoying but real social cost of all the bikeshedding and bickering.
All of those are costs are at least as high for non-hybrid. The spec and API are just as easy to design (because we have really good and simple ECC libraries), and the bikeshedding and bickering will be a lot less if people stop trying to force pure PQC algorithms that lots of people see as incredibly risky for incredibly little benefit.
reply