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

[2] https://tools.ietf.org/html/rfc5932

[3] https://news.ycombinator.com/item?id=12360557

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.

NIST usually doesn't standardize algorithms just because. Which is reasonable, because having more algorithms doing the same thing only creates confusion and more sources for error. New algorithms should only be introduced when they serve a need or when the existing algorithms have weaknesses. The likely next algorithm standardization process NIST is going to start is about Post Quantum cryptography. However NIST has lost a bit of its relevance with the IETF taking over after questions about NSA influence over NIST.

Btw, there is no requirement for NIST algs to be US-based. E.g. AES was developed in Belgium.

Belgium is an America loving country though, like all of western Europe as far as I know, and Americans usually quite aware who the friends and 'terrorists' are. I wonder if AES had been from, I don't know, Kenya or Kazakhstan or Bolivia, if it had had much chance at all (though I'm not up to date on the exact America-sentiment in each of those countries, we hardly hear about them in Western news).

Rijndael, the Belgian cipher in question, famously won a very well-regarded cryptographic contest to obtain its role as AES. "Belgium" has nothing to do with it.

I know it was a Belgian cryptographer, not Belgium the state. I still think the country has makes a difference in how people regard an entry for the contest.

Cryptographic algorithm competitions are more rigorous than beer competitions.

Of course, but do you think an algorithm from a state that most Americans see as "behind" or even a "terrorist state" has a perfectly equal chance of winning? The judges might even explicitly try to give each an equal chance but at least subconsciously, I would expect there to be some bias.

You can read about the AES process here with many detailed references you can follow up on.

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard_p...

The submitters were not countries but (typically groups of) practitioners. Only one proposal was made by a group consisting entirely of Americans and it did not win. Like all such processes, I'm sure this particular one was imperfect and could be made better. You're making it sound like the judging of an Olympic Ice Dancing event, though, and I think all available evidence suggests that it wasn't.

AES beat out American ciphers from the likes of Bruce Schneier and David Wagner.

NIST is agency of the United States Department of Commerce.

Yes but NIST holds requests for crypto standards that are used widely around the world. As far as I know there's no requirement that the algorithm be created in the United States to be considered, but I'm not entirely sure about the process.

It seems to me that if the standard was better, faster, and more secure, then it would become the greater standard by merit. Unfortunately there's been a shadow on NIST since Dual_EC_DRBG was "pushed" through. I would like to think it's greater mission is still intact.

Rijndael (which is better known by the name AES) was developed by Belgian cryptographers, working in Europe. I think the same team developed Keccak (SHA-3).

For some additional context:

Vincent Rijmen and Joan Daemen are the co-designers of AES. Later, they collaborated with Gilles Van Assche and Michaël Peeters to design NOEKEON for the NESSIE competition [1]; simultaneously Rijmen worked with Paulo S. L. M. Barreto to design the WHIRLPOOL hash function [2], which became a NESSIE recommendation.

Daemen, Van Assche, and Peeters were joined by Guido Bertoni to create the hash function RadioGatún [3] from Daemen and Craig Clapp's old stream cipher PANAMA [4]. The same team refined the design into Keccak [5], a 'sponge function' primitive they invented [6] that forms the basis of SHA-3.

[1] http://gro.noekeon.org/ [2] http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html [3] http://radiogatun.noekeon.org/ [4] http://radiogatun.noekeon.org/panama/panamadc.pdf [5] http://keccak.noekeon.org/TheRoadFromPanamaToKeccak.pdf [6] http://sponge.noekeon.org/

The uncertainty around their origin (a foreign country who until a few years ago was hostile to the US) would preclude them being used by US government agencies (who depend on NIST for the stamp of approval).

Is that true for an open-source algorithm? I'm sure that the Russian Government still uses things like SHA256, even though it's an approved NIST standard.

I would imagine so, particularly in cryptography, being able to view the source is not the same as being able to (easily) verify it doesn't contain any backdoors. See ECDSA as good example; we can see the entire standard and yet we can't be sure that it hasn't been weakened/backdoored by its creators despite it looking secure on the surface. See the start of [0], the bit about the standard pushing state leaking through secret dependent operations.

[0] https://blog.cr.yp.to/20140323-ecdsa.html

Edit: my point here is that America would have to trust that there was no way that the Russians had added backdoors. Given their history and the current political climate I can't see that trust coming soon.

You can go a long way towards showing a standard hasn't been backdoored by showing the parameters were generated by 'nothing up your sleeve' numbers. E.g. start trying RSA keys at SHA-256 of 1. And keep incrementing until requirements are met.

When it comes to military or digital signatures - it's gost block cipher, gost hash functions and gost ec signatures.

No, it does not. GOST algorithms usage is a must inside government structures without any exceptions.

Incorrect, a lot of people don't know but it was the NATO and the united states that was actually actively hostile to russia. (long family history of military folks who had EYES only access.)

Why, exactly, would NIST standardize GOST? What other ciphers should it standardize? So far, it's done DES and, to replace DES, AES. Why GOST and not Salsa20 --- which people in the real world actually use?

Standardizing multiple ciphers defeats NIST's whole purpose. The whole point is to have one standard block cipher. That, incidentally, is also the point of GOST.