One thing I don't really talk about much is that most of my designs work within HTTP and do not rely on DNS.
There are two reasons for this:<li>I want to support Onion Services and Tor users in general.</li><li>DNSSEC evangelism sucks.</li>
Me: We all know PGP is bad because it forces you to support legacy bullshit like 1024-bit RSA keys, but I'm specifically going to write a blog post about email encryption as not just a technical challenge.
@Delta Chat: *subtoots my blog post*
Their source code: Disables TLS security to support legacy 1024-bit RSA.
Everything You Need to Know About Email Encryption in 2026
If you think about emails as if they're anything but the digital equivalent of a postcard--that is to say, they provide zero confidentiality--then someone lied to you and I'm sorry you had to find out from a furry blog that sometimes talks about applied cryptography. CMYKat At the end of 2025, at the 39th Chaos Communications Congress in Hamburg, Germany, a team of security researchers posted some devastating…
It might not make much difference, but every time I see a news headline that describes a Republican politician raping children as "had sex with", I email the editors to correct their misuse of language.
I know it will probably fall on deaf ears, but the more people do this, the greater the chances they'll listen.
Announcing Key Transparency for the Fediverse
I'm pleased to announce the immediate availability of a reference implementation for the Public Key Directory server. This software implements the Key Transparency specification I've been working on since last year, and is an important stepping stone towards secure end-to-end encryption for the Fediverse. You can find the software publicly available on GitHub: PHP Server software: PHP SDK (client-side):
If I ever strike it rich, I'm probably going to spend a good 6-8 months working on open source stuff that will make devs' lives easier and improve security overall.
Re: https://old.reddit.com/r/crypto/comments/1pca3r8/introducing_constanttime_support_for_llvm_to/nrzywmp/?context=2
It is simultaneously true that:<li>Most data breaches do not require any cryptographic wizardry</li><li>Of the ones that involve cryptography, side-channels (timing, power, etc.) are not an attacker's first choice</li><li>The inability to have guarantees that the compiler will not make code variable-time as part of an "optimization" is a massive pain point in writing secure implementations of cryptography</li>
And, sure, the LLVM work won't stop app developers from fucking up something on the OWASP Top 10 list for a given year. Nor will it stop phishing from being hella effective against most users and services.
But it does reduce compiler doom and various forms of auditor bikeshedding, which makes applied cryptography work a little easier to get done.
And the best mitigation we have for phishing attacks today is WebAuthn... which uses cryptography. :P
Sometimes, naysaying is actually counterproductive.
