Tanja Lange wrote: >* 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.
It was never a secret that A5/2 was an export cipher offering only 40-bit security. This was well known to the countries and operators that, due to export restrictions, were barred from purchasing A5/1. A5/1 was designed to meet West German security requirements for protecting its citizens against eavesdropping by East Germany. I do not believe the governments designing A5/1, A5/2, GEA1, GEA2, and COMP-128-1 intentionally made them weaker than what export limits required. They were designed to have good performance on the extremely limited hardware (mobile phones and SIM cards) of the late 1980s. By comparison, the later industry-designed E0 cipher for Bluetooth, which faced similar hardware limits, turned out significantly weaker than these secret, government-designed ciphers. GSM gets an unfairly bad reputation. In a historical context, it was the first mass-market encryption system, paving the way for the widespread encryption we rely on today. It was only designed to last 10 years; the real issue is that it is still in use. Legacy technologies like GSM, GPRS, and TETRA should have been phased out long ago, and it is frustrating that modern phones still do not allow users to disable 2G entirely. Note: These legacy 2G ciphers have no connection to modern systems. While 2G crypto was government-designed, 3G through 6G cryptography was designed by the industry group ETSI SAGE, resulting in public and highly secure algorithms. https://www.ericsson.com/en/blog/2021/6/evolution-of-cryptographic-algorithms Cheers, John Preuß Mattsson On 2026-07-09, 15:17, "Tanja Lange" <[email protected]> wrote: On Thu, Jul 09, 2026 at 12:44:02PM +0000, Peter Gutmann wrote: > Tanja Lange <[email protected]<mailto:[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]
