5 ms·

> "Why those algorithms could be interesting and great worth alternative to foreign ones? Because they are obviously not worse, in some places are much better a

> "Why those algorithms could be interesting and great worth alternative to foreign ones? Because they are obviously not worse, in some places are much better and have high serious security margin." Is there a reason these algorithms aren't formally introduced as NIST standards? Are they copyrighted? Couldn't anyone submit them?

tptacek 10y ago
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.
yarrel 10y ago
NIST is agency of the United States Department of Commerce.
- matt_wulfeck 10y ago
  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.
  - wiml 10y ago
    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).
    - niftich 10y ago
      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/ http://gro.noekeon.org/ [2] http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html [3] http://radiogatun.noekeon.org/ http://radiogatun.noekeon.org/ [4] http://radiogatun.noekeon.org/panama/panamadc.pdf http://radiogatun.noekeon.org/panama/panamadc.pdf [5] http://keccak.noekeon.org/TheRoadFromPanamaToKeccak.pdf http://keccak.noekeon.org/TheRoadFromPanamaToKeccak.pdf [6] http://sponge.noekeon.org/ http://sponge.noekeon.org/
chiph 10y ago
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).
- barnassey 10y ago
  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.)
- matt_wulfeck 10y ago
  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.
  - andwur 10y ago
    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 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.
    - rocqua 10y ago
      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.
  - 10y ago
hannob 10y ago
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.
- lucb1e 10y ago
  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).
  - tptacek 10y ago
    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.
    - lucb1e 10y ago
      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.
      - pvg 10y ago
        Cryptographic algorithm competitions are more rigorous than beer competitions.
        10y ago
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.

tptacek 10y ago

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.

yarrel 10y ago

NIST is agency of the United States Department of Commerce.

matt_wulfeck 10y ago
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.
- wiml 10y ago
  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).
  - niftich 10y ago
    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/ http://gro.noekeon.org/ [2] http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html [3] http://radiogatun.noekeon.org/ http://radiogatun.noekeon.org/ [4] http://radiogatun.noekeon.org/panama/panamadc.pdf http://radiogatun.noekeon.org/panama/panamadc.pdf [5] http://keccak.noekeon.org/TheRoadFromPanamaToKeccak.pdf http://keccak.noekeon.org/TheRoadFromPanamaToKeccak.pdf [6] http://sponge.noekeon.org/ http://sponge.noekeon.org/

chiph 10y ago

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).

barnassey 10y ago
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.)
matt_wulfeck 10y ago
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.
- andwur 10y ago
  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 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.
  - rocqua 10y ago
    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.
- 10y ago

hannob 10y ago

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.

lucb1e 10y ago
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).
- tptacek 10y ago
  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.
  - lucb1e 10y ago
    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.
    - pvg 10y ago
      Cryptographic algorithm competitions are more rigorous than beer competitions.
      - 10y ago

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.