On Thu, Jul 09, 2026 at 12:44:02PM +0000, Peter Gutmann wrote:
> Tanja Lange <[email protected]> writes:
>
> >Maybe it just was a rethorical quations, but here is a quick brain dump,
> >sorry if I missed anybody's favoite:
>
> All of those are implementation errors:
>
> - If you implement known-broken crypto, it's an implementation error.
> - If you implement RSA with too-short keys, it's an implementation error.
> - If your implementation chooses weak primes for RSA, it's an implementation
> error.
> - If you get RSA padding wrong, it's an implementation error.
>
> More generally, if you implement crypto badly, it's an implementation error.
> For example if I implement RSA with p = q, that's a (pretty bad)
> implementation error.
>
I give you that export-grade crypto was always a bad idea.
All others in my lists were considered secure^* when people started deploying
them. Now you won't deploy MD5, in 1992 you would have considered it state of
the art. It's not an implementation error but broken crypto, same for the
others.
If you call that an implementation error you're redefining the meaning outside
the common meaning, and not fitting with the statement that Orr quoted (as it
doesn't make sense with the stated distinction).
All the best
Tanja
* Some people certainly knew the hidden vulnerabilities in A5/2 and TETRA. Is
it an implementation error to trust untrustworthy sources? I won't blame the
implementer, but those who let those get into standards and chosen as defaults.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
