@urig it doesn't really matter, it's just two different ways to encode the key. The main difference is that SPKI encodes the key type, but you know that with DKIM anyway. The mere problem is that the standard says something and reality is another thing.

@bartavi no security risk, it's just a "if you dare to follow the standard, your emails may not be delivered"-risk.

Key serialization formats can be - uh - the source of "interesting" issues. It appears the whole internet technically uses DKIM the wrong way, but it's more or less the fault of the standard.
DKIM uses public keys in DNS, usually RSA, but how are they encoded? There are two common RSA public key formats, SPKI and PKCS#1.
The DKIM spec RFC 6376 says this should be an RSAPublicKey and references RFC 3447, which is PKCS #1. So it's PKCS #1, right?
Well... there's an "INFORMATIVE" part of the RFC that lists openssl commands to encode a key, with an example. And that's... the openssl command to generate SPKI. The example shown is also an SPKI key.

The Internet has voted with its feet and everyone uses SPKI. From previous research, I had a collection of ~35k DKIM keys, and there are zero PKCS#1 keys in there.

This appears to be known and is mentioned in the errata.

It's quite an unfortunate situation. Technically, everyone's doing it wrong. However, if you would happen to be so brave to try to do it right, you'll probably just run into problems. While I haven't tested it, my best guess is that you will almost certianly find some receivers accepting PKCS#1 and others not. (Many crypto library APIs autodetect the format, but given *noone* is using PKCS#1, I'm sure there will be ones only accepting SPKI.)

@heinleinsupport Und falls Ihr das seht und jetzt badkeys mal testen wollt: https://badkeys.info/

Mit dem Open-Source-Tool #badkeys kannst Du öffentliche kryptographische Schlüssel auf bekannte Schwachstellen untersuchen. Auf unserer Secure #Linux Administration Conference 2025 zeigt Dir Hanno Böck, der das Tool selbst entwickelt hat, wie man badkeys nutzen kann, um Sicherheitslücken in der eigenen IT-Infrastruktur zu vermeiden.

👉 Jetzt ein Ticket für unsere #SLAC vom 2.-4. Juni 2025 in Berlin sichern und mehr erfahren:

https://www.slac-2025.de

#slac2025 #OpenSource #CyberSecurity

Jenkins recently announced that their docker images ssh-agent (CVE-2025-32754) and ssh-slave (CVE-2025-32755) had pregenerated, static SSH host keys. They're now detected by badkeys. https://www.jenkins.io/security/advisory/2025-04-10/

JSON Web Keys have a very peculiar property. It is a cryptographic key serialization format where public and private keys look almost the same. The only difference is that private keys contain more values. This means one can accidentally use a private key instead of a public key. Which works, but isn't very secure.
After my recent presentation at the @owasp_de Day, I was asked to have a look at OpenID Connect keys. Which are, well, in JWK format. I guess you can see where this is going.
https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html

The new badkeys release (0.0.13) adds support to scan JSON Web Keys and JSON Web Key Sets directly with badkeys.

I recently realized something that I hadn't noticed before. In RSA, we call the privat key value "d". In elliptic curve cryptography, we also call the private key value "d". Is this a coincidence, or was this some deliberate choice? (FWIW, this isn't true for the public key, in RSA, this is composed of two values R and e, in ECC, it's usually x and y, but it's complicated... )

Updates on the Fortinet incident: badkeys now detects a more complete set of affected keys, and I have also identified 314 keys for active ACME accounts for @letsencrypt in the data. I have disabled the affected ACME accounts. Some updates in the blogpost: https://blog.hboeck.de/archives/908-Private-Keys-in-the-Fortigate-Leak.html

@christopherkunz @GossiTheDog nothing spectacular, random small company webpages and some likely internal hostnames.

Something about that Fortinet/Fortigate leak that has not been widely recognized/reported yet: there are some private keys in there. Some of them belonged to unexpired, unrevoked certificates. I have reported all affected certificates to the responsible CAs.

badkeys now has detection for those keys. (yet, based on incomplete data.)

More info: https://blog.hboeck.de/archives/908-Private-Keys-in-the-Fortigate-Leak.html

@GossiTheDog @christopherkunz

I discovered a certificate using a "public private key", in this case a key that is part of OpenSSL's test suite. This would not necessarily be a particularly interesting event. It happens every now and then that people use private keys they find on the Internet, likely due to a lack of understanding of public key cryptography. I usually report them for revocation, and move on. However, this one is a bit more unusual. It has been issued by the CA Digicert - for a domain owned by Digicert. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/d21mtDJ7YXQ

Followerpower: There's a W3C standard called XML Key Management Specification. It's, essentially, a way to encode RSA public and private keys in XML. Does this have practical relevance? Any protocols or software that use it?

I'll talk about badkeys today (1:40pm CET) at the German OWASP Day @owasp_de and there's a livestream https://infosec.exchange/@owasp_de/113474729662238976

Unfortunately, I had to cancel my planned presentation about badkeys on Saturday at the BSides Berlin conference due to a Covid-19 infection...
https://infosec.exchange/@badkeys/113306827602411315
For anyone who wanted to see it: I'll be giving a similar presentation at the German OWASP Day, and I've been told it'll be recorded and there will be a video.

I'll be giving a talk about badkeys at the German OWASP Day @owasp_de in Leipzig (Nov 13th) https://god.owasp.de/2024/program-detail.html?talk=talkEight

On October 26th, I will be giving a talk about badkeys at the BSides Berlin conference https://bsides.berlin/#/speakers?lang=en&sessionId=17594000000720068

However, there's also some less good news in relation to this:
@nlnet has been funding open source projects via a program financially supproted by the @EUCommission - but current plans are to stop that funding by 2025. It appears the commission does not consider supporting open source security and internet infrastructure software to be that important any more. See also @fsfe 's info here: https://fsfe.org/news/2024/news-20240719-01.en.html

Good news for badkeys: the project will receive funding via the NGI0 Core Fund by @nlnet @EUCommission - this will allow the implementation of some significant improvements and additional uses of badkeys' functionality. Notably, the detection of "known public private keys" will be expanded by auto-sourcing keys from various sources, I will set up some regular monitoring of WebPKI, DKIM, and DNSSEC keys for vulnerabilities, and there will be an automated WebPKI revocation service for compromised keys. https://nlnet.nl/project/badkeys/