libroot

Again you responded to a position I havent taken. My argument was about who holds procedural power in standards bodies, given that some of the significant participants (NSA & GCHQ) have funded programs with hundreds of millions of $ per year to make deployed cryptography exploitable. And DES and Dual EC and others are what that looks like when it succeeds.

What a weird comment.

> where you think NSA "proposed" MLKEM or had some hand in its design

Never said this and don't think it.

Kyber came from an academic team through an open NIST competition, no one is disputing that. The fight is over a spec for deploying ML-KEM without the ECC layer, and the fact that NSA and GCHQ are argumenting that that weakening is a good thing, and about corrupt standardization process.

Imo "the optimal choice" is to be extremely skeptical to what comes to NSA proposing anything related to encryption/cryptography. From the first part of this blog series by DJB[1]:

> Try to put yourself in the mindset of NSA as an attacker. You have a massive budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; "to the consumer and other adversaries, however, the systems' security remains intact". One of your action items is to "influence policies, standards and specification for commercial public key technologies". Another is to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS".

And when you read the Snowden docs and you come across to things like this 2010 GCHQ presentation[2], stating "for the past decade, NSA has lead an aggressive, multipronged effort to break widely used Internet encryption technologies" such as "SSL" and "SSH" and "VPNs"; that "cryptanalytic capabilities are now coming on line"; and that "vast amounts of encrypted Internet data which have up till now been discarded are now exploitable."

So we have these agencies like NSA and GCHQ, with stated, funded programs to make deployed cryptography exploitable (and historical evidence of them successfully doing just that)... It's an unbelievable conflict of interest for them to hold any role where they can shape what gets deployed. Absolutely bonkers.

And on DES specifically, it was both at once, not a binary. NSA in secret pushed IBM to cut the key size, while strengthening the algo against every attack except brute force. The design criteria were classified and IBM's own research docs were literally locked up under gov classification at NSA's request meanwhile when IBM personnel publicly denied any NSA involvement (and the NSA director publicly denied any algo weakening, again, a lie). So DES came out genuinely hardened against differential cryptanalysis but at the same time breakable by brute force by organizations with budgets like NSA's, by NSA's request/order.

For the "blue team" thing.. I guess it's actually better for them tactically to not spin off, because being NSA gives you authority in those circles. Standards bodies don't seem to treat the conflict of interest as a problem (as we can see), but rather as a qualification ("people who know cryptography best").

1: https://blog.cr.yp.to/20251004-weakened.html 2: https://web.archive.org/web/20240420184725if_/https://cdn.pr...

This is also relevant if you get the phone back. There could be some nasty hw modifications that could leak data out of the phone in AFU state. Hopefully people in these kinds of situations take this into account. IMO all phones and computers should be treated as unsafe to unlock after they've been seized.

> Posted new paper "Exploiting ML-DSA bugs" and demo scripts: https://cr.yp.to/papers.html#mldsa The current panic to roll out new ML-DSA code in place of ECC signatures will give away tons of keys to attackers through the predictable flood of efficiently exploitable software vulnerabilities. https://mastodon.cr.yp.to/@djb/116677083993481766

Yes, the journalists did the redactions. The metadata timestamps in one of the documents show that the versions were created three weeks before the publication.

And to be honest, the journalists generally have done a great work on pretty much in all the other published PDFs. We've went through hundreds and hundreds of the published documents, and these two documents were pretty much the only ones which had metadata leak by a mistake revealing something significant (there are other documents as well with metadata leaks/failed redactions, but nothing huge). Our next part will be a technical deep-dive on PDF forensic/metadata analysis we've done.

Thank you. The most recent completely new information from the Snowden files is found in Jacob Appelbaum's 2022 thesis[1], in which he revealed information that had not been previously public (not found on any previously published documents and so on). And AFAIK, the most recent new information from the published documents (along with this post) might actually be in our other posts[2], but there might be some others we aren't aware of.

[1]: https://www.electrospaces.net/2023/09/some-new-snippets-from...

[2]: Part 2: https://libroot.org/posts/going-through-snowden-documents-pa...

and part 3: https://libroot.org/posts/going-through-snowden-documents-pa...

Weird, the certificate should be fine. Here's a link for Web Archive: https://web.archive.org/web/20251211220119/https://libroot.o...

We also have Tor onion site: http://librootfuuucybrkpvarmpswsxnbsakf2oqqzxncvsqrvc2j73kuu...

And I2P: http://xvqmnhevx32br7m4e7g3yoxfirizo4m3uktym3wnuntbgbr5bvna....

No, these encrypted VMs are not protected from buggy or malicious on-die components. SEV assumes that the SoC hardware is trusted.[1] And we don't even have to go that deep: both AMD SEV and Intel's equivalent, Intel SGX, have historically been vulnerable to side-channel and speculative-execution attacks, among others, that can undermine their isolation guarantees.[2]

[1]: "As with the previous SEV and SEV-ES features, under SEV-SNP the AMD System-on-Chip (SOC) hardware, the AMD Secure Processor (AMD-SP), and the VM itself are all treated as fully trusted." https://www.amd.com/content/dam/amd/en/documents/epyc-busine...

[2]: https://libroot.org/posts/trusted-execution-environments/

It's hard to take corporate denials at face value. History shows that when it comes to surveillance and government cooperation, big tech companies often say one thing in public while doing another behind closed doors.

Before the Snowden revelations, firms like Microsoft, Google, and Apple explicitly denied participating in any form of mass-surveillance. They insisted they only complied with lawful, targeted requests and never provided "direct access" to their systems. Yet the Snowden documents revealed that the NSA's PRISM program did, in fact, collect data directly from these same companies. Other programs like XKEYSCORE showed how that data was searched and analyzed at scale without meaningful oversight.

Even after the Snowden disclosures, the denials (read: lies) continued. Microsoft, for example, repeatedly claimed it "does not provide any government with direct or unfettered access to customer data" and only discloses data when "legally compelled."[1] But we now know that Microsoft works with the NSA to enable pre‑encryption access to Outlook emails, Skype calls, and SkyDrive files, and that the NSA has direct access to Microsoft's systems through PRISM, directly contradicting the company's public statements.[2]

It's scary how easily people believe what these big companies say. Even the EFF praised Microsoft's 2013 transparency report just months before the Snowden revelations, showing how effective these PR strategies are.[3]

When Cloudflare says it doesn't engage in mass-surveillance, we should treat that claim with extreme skepticism. History demonstrates how easily a platform with this level of access can be misused or quietly co-opted by intelligence agencies.

[1]:

10/20/2025

> "Microsoft discloses customer data only when legally compelled to do so. Microsoft does not provide any government with direct or unfettered access to customer data. Microsoft does not provide any government with direct or unfettered access to customer data. Microsoft does not provide any government with our encryption keys or the ability to break our encryption." https://www.microsoft.com/en-us/corporate-responsibility/rep...

06/07/2013

> "If the government has a broader voluntary national security program to gather customer data we don’t participate in it." https://news.microsoft.com/source/2013/06/07/statement-of-mi...

07/11/2013

> "To be clear, Microsoft does not provide any government with blanket or direct access to SkyDrive, Outlook.com, Skype or any Microsoft product." https://news.microsoft.com/source/2013/07/11/statement-from-...

[2]:

> At Microsoft, as The Guardian has reported, the N.S.A. worked with company officials to get pre-encryption access to Microsoft’s most popular services, including Outlook e-mail, Skype Internet phone calls and chats, and SkyDrive, the company’s cloud storage service. https://archive.is/DyVgN

> the Guardian revealed that the NSA claimed to have "direct access" through the Prism program to the systems of many major internet companies, including Microsoft, Skype, Apple, Google, Facebook and Yahoo. https://www.theguardian.com/world/2013/jul/11/microsoft-nsa-...

> these systems allow analysts to listen to whatever emails they want, whatever telephone calls, browsing histories, Microsoft Word documents.

> And it's all done with no need to go to a court, with no need to even get supervisor approval on the part of the analyst

> all an analyst has to do is enter an email address or an IP address, and it does two things. It searches that database and lets them listen to the calls or read the emails of everything that the NSA has stored, or look at the browsing histories or Google search terms that you've entered, and it also alerts them to any further activity that people connected to that email address or that IP address do in the future

https://abcnews.go.com/blogs/politics/2013/07/glenn-greenwal...

[3]:

03/21/2013 https://www.eff.org/deeplinks/2013/03/victory-transparency-m...

Sure, threat models matter, but that's exactly the point. TEEs are marketed as if they solve the "malicious infrastructure" problem. Cloud providers tell you they can't see your data, and vendors pitch TEEs as some kind of hardware-rooted guarantee. If your threat model is "malicious sysadmin" or "host operator" then the fact that the root of trust is opaque, unauditable, and repeatedly compromised does matter.

Saying "what's your alternative" also misses the criticism. The issue isn't whether TEEs can reduce some threats compared to no isolation at all. Obviously they can in some scenarios. The issue is that their trust model is misrepresented: you're still trusting vendors and firmware you can't inspect, and history shows that trust is often misplaced. That's not "no alternative", that's "don't build your security story on black boxes with a track record of holes."

If the only way TEEs "work" is if you lower your expectations to "slightly better than nothing," then the marketing and security claims around them are deeply misleading. At that point, calling them "trusted" environments is just branding, not security.

> Additionally, you still get attestation which gives you cryptographic proof of what code is running.

Remote attestation ultimately relies on the same implicit trust it claims to replace. For example this paper[1] from 2019 showed how AMD's PSP secure boot can be compromised, giving an attacker an possibility to load a patched firmware that grants arbitrary read/write access to the PSP memory, which then allows the attacker to extract the Chip Endorsement Key (CEK), which is AMD's attestation root key. Once you have the CEK, you can forge attestation reports (for example impersonate a legitimate SEV platform) or bypass attestation entirely. And the CEK had (changed in 2023) an infinite lifetime and there was no rollback protection, so even if AMD issued a firmware update, attackers could revert to the old vulnerable firmware and re-extract the CEK.

[1]: https://arxiv.org/pdf/1908.11680

Edit:

And very recently, the new Battering RAM[2] (Sep 2025) and WireTap[3] (Oct 2025) attacks have broken Intel SGX and AMD SEV-SNP remote attestations.

[2]: https://batteringram.eu/

[3]: https://wiretap.fail/