I reported an insecure DKIM key to Deutsche Telekom / T-Systems. They first asked me to further explain things (not sure why 'Here's your DKIM private key' needs more explanation, but whatever...). Then they told me it's out of scope for their bugbounty.

I guess then there's really no reason not to tell you: They have a 384 bit RSA DKIM key configured at: dkim._domainkey.t-systems.nl

384 bit RSA is... how shall I put it? I think 512 bit is the lowest RSA key size that was ever really used. 384 bit RSA is crackable in a few hours on a modern PC (using cado-nfs). The private key is:
-----BEGIN RSA PRIVATE KEY-----
MIHxAgEAAjEAtTliQYV2Xvx1OGkDyOL799BTFEuobY2dn2AgtiKCQgrh78NVK1JK
j0yRXgNnPpGBAgMBAAECMF0t+TBZUCi8xATSMij7VLTxv5Xi5OIXesNiXOKtYIRP
LkpYfR5PggaMScfbmqSssQIZAMwOhm9d7Y7Qi7I2j1AlYbiqdtqO54T7FQIZAONa
9dJFkC6lM3EPXR+0SZ4dqwwpiM0nvQIYYgz8thi5JK264ohq9sTvnu9yKvUN9I09
AhgfgMYZKcxtujRjkSZtMzUUNLYzzDmJe90CGDKwqcBI0v9ChaR8WHht+/chMdxj
7ez94w==
-----END RSA PRIVATE KEY-----

Average number of hours between #curl security reports

Material for a pending presentation

I wrote up in the TLS mailing list why I think composite signatures (ML-DSA + ECDSA/RSA) are a net negative, will hurt the ecosystem, and should not be implemented.

Hybrid key exchange was simple and self-contained. Hybrid signatures would be a mountain of complexity in code responsible for half of sev:crit in crypto libraries since 2020.

https://mailarchive.ietf.org/arch/msg/tls/oh3jmmkHzHdp1hk4R4M9QjkmvBk/

Are "device bound session credentials" really device bound, or is that a nice name for something that's hard to steal and use?

When I look at https://developer.chrome.com/docs/web-platform/device-bound-session-credentials , it looks like the attacker can steal them, but only use them in the next ten minutes?