4 ms·

Lack of interest on behalf of the author, lack of interest on behalf of the standards body, implicit political pride, lack of internationally-recognized, system

by niftich 10y ago

Lack of interest on behalf of the author, lack of interest on behalf of the standards body, implicit political pride, lack of internationally-recognized, systemic cryptanalysis. It'd be an entirely different matter if NIST posted a new competition and someone entered an algorithm that just happened to be an existing Russian standard. Altogether, this isn't an unpleasant status quo. These algos are standards in their sphere of influence; other spheres of influence (like NIST) aren't showing much interest in evaluating their fitness for use because it's not necessary for them -- they already have comparable standards. However, it's more of an issue for someone like IETF who tries to promulgate standards with a global reach. They are simultaneously trying to be accommodating while trying not to make recommendations that are objectively bad (e.g. recommending a broken algorithm, despite it being a national standard). There is a now-expired draft RFC for some GOST algos in TLS [1], and there's an RFC for supporting the Japanese-origin Camellia block cipher in TLS [2], although all major browsers have since removed support for it, mostly born out of a blog post about reducing supported TLS ciphersuites but also citing lack of use [3]. [1] https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 [2] https://tools.ietf.org/html/rfc5932 https://tools.ietf.org/html/rfc5932 [3] https://news.ycombinator.com/item?id=12360557 https://news.ycombinator.com/item?id=12360557

tptacek 10y ago
There are basically three kinds of ciphers: * The kind, named "AES", that are implemented in hardware on a bunch of different mainstream platforms. * Ciphers that were designed to be fast on general-purpose CPUs (for instance: that have good multipliers) and are thus cycles/byte competitive. Salsa/Chacha is the best-known example here, and currently only one with widespread use (this used to be the bucket RC4 was in). * Ciphers that nobody uses unless a government mandates it. There might be a case for having two bulk cipher specs, one for hardware acceleration and one for software. That's how eSTREAM did it. There's really not much of a case for standardizing, or really even adopting, other ciphers. Things are different in signature-land, or key-agreement-land, or even hash-land. They're definitely different in AEAD-land. But for bulk encryption primitives, we may be at a happy place already.

by niftich 10y ago

tptacek 10y ago

There are basically three kinds of ciphers: * The kind, named "AES", that are implemented in hardware on a bunch of different mainstream platforms. * Ciphers that were designed to be fast on general-purpose CPUs (for instance: that have good multipliers) and are thus cycles/byte competitive. Salsa/Chacha is the best-known example here, and currently only one with widespread use (this used to be the bucket RC4 was in). * Ciphers that nobody uses unless a government mandates it. There might be a case for having two bulk cipher specs, one for hardware acceleration and one for software. That's how eSTREAM did it. There's really not much of a case for standardizing, or really even adopting, other ciphers. Things are different in signature-land, or key-agreement-land, or even hash-land. They're definitely different in AEAD-land. But for bulk encryption primitives, we may be at a happy place already.