7 ms·

GOST cryptography – Russian Federation’s cryptographic algorithms

84 points by stargrave 10y ago

matt_wulfeck 10y ago
> "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.
contingencies 10y ago
Some projects, such as Gentoo, use multiple hashing algorithms in parallel to protect against potential collision attacks while verifying package sources. Adding Streebog for diversity may be a good idea.
- hannob 10y ago
  Actually Gentoo stopped doing that. (Which imho is sane. It's useless overhead for a completely theoretical scenario that will never happen.)
  - tptacek 10y ago
    It was very sane in the 1990s, when hash combiners were invented and designed by Paul Kocher into SSL 3.0. The hashes we had to work with then were basically first generation designs, preceding the first wave of major cryptanalytic results against hashes. An MD5/SHA1 hash combiner made sense. It is less sane now, I agree. With the possible exception of PQ schemes, cascades of all kinds are a silly idea.
    - hannob 10y ago
      Well, I'd say we can pretty clearly pinpoint when cascading schemes makes sense: When we have different algs with different security properties and we can't have them all in one algorithm then cascading makes sense. This is the case for newhope + x25519, because one is based on well known crypto, but not quantum safe, the other is based on not so well known crypto, but (maybe) quantum safe. You could make similar arguments in the past about hash functions when the analysis around their safety was much more fuzzy. (Which is why I can also understand why Gentoo decided way back to combine sha2+whirlpool.)
  - contingencies 10y ago
    I think perhaps portage simply stopped winking ;-) at you while validating package sources on a per-algorithm basis. Typical Manifest file: DIST <filename> <size> SHA256 <sha256_checksum> SHA512 <sha512_checksum> WHIRLPOOL <whirlpool_checksum> Looks like SHA256, SHA512 + Whirlpool to me. Apparently the SHA algorithms have FIPS (US) and NESSIE (EU) certification. Whirlpool has NESSIE (EU) certification. Streebog has GOST (Russian) certification. Added https://bugs.gentoo.org/show_bug.cgi?id=597736 https://bugs.gentoo.org/show_bug.cgi?id=597736 for discussion.
tormeh 10y ago
So, if you encrypted a file with a NIST algorithm and then encrypted the resulting file again with a GOST one, would that make it secure?
- kkl 10y ago
  That is called a "cipher cascade"[1] and practically speaking, no. [1] https://en.wikipedia.org/wiki/Multiple_encryption https://en.wikipedia.org/wiki/Multiple_encryption
  - code_sardaukar 10y ago
    I think you're missing the implication in the original comment, that the NSA has put a backdoor into NIST and the Russian equivalent has put a backdoor into GOST, but neither can use the other's backdoor.
    - ex3ndr 10y ago
      We have done double encryption based on same ideas.
      - tptacek 10y ago
        I cannot tell you how silly this is. If you're using GOST, you're no longer building NIST-compliant crypto. If you're using NIST, you're no longer building GOST-compliant crypto. For Christ's sake, just stop using standardized crypto if you're worried about backdoors like this. Use an eSTREAM portfolio cipher for bulk crypto, use Blake2 as your hash, and use Curve448 for key agreement and signatures. You can just use the Noise protocol framework to accomplish this, which was designed to use all of these components.
        hueving 10y ago
        It's still NIST compliant crypto on the outside regardless of the inner contents. Assuming NIST(GOST(plaintext)), NIST would be terribly broken if using GOST ciphertext as the payload weakened the security. It's crypto 101 that, given a ciphertext without the key, an algorithm's correct input should be indistinguishable from random input of the same length. I'm shocked that you think the plaintext contents would have an affect on whether or not something is NIST compliant.
eternalban 10y ago
I don't get these crypto types that use plain http for the download page [1] and then make a show with "You have to verify downloaded tarballs integrity and authenticity to be sure that you retrieved trusted and untampered software." And if you go to the "alternate resources" links[2][3], you get "Error code: sec_error_cert_signature_algorithm_disabled." [1]: http://www.cypherpunks.ru/gogost/Download.html#Download http://www.cypherpunks.ru/gogost/Download.html#Download [2]: https://lists.cypherpunks.ru/mailman/listinfo/gost https://lists.cypherpunks.ru/mailman/listinfo/gost [3]: https://git.cypherpunks.ru/cgit.cgi/gogost.git/ https://git.cypherpunks.ru/cgit.cgi/gogost.git/
- fulafel 10y ago
  End-to-send security is much better than the in-flight protection TLS gets you, and even that only as far as you trust the half-assed pki. I imagine most crypto experts don't put much faith in the integrity of their hosting providers and are not in the business of opsec themselves. Of course end-to-end only helps if people actually perform the check... TL;DR They probably think TLS in software distribution = false sense of security.
- stargrave 10y ago
  PKI is a business model. That download page suggests you to verify downloaded tarballs with OpenPGP key, or visit Git repository to look for signed (OpenPGP again) tags there. Of course you have to setup some kind of trust for verifying keys. If your browser shows you such kind of errors, then seems that you do not trust CAcert.org used for certificate creation. You may retrieve OpenPGP keys and find signature you may trust. PKI (HTTPS) is single point of trust, OpenPGP provides much more ones.
  - deleted 10y ago
    [deleted]
- nullc 10y ago
  If your primary threat model is an active attacker in proximity to the server, rather than the client, SSL provides _NO_ security: The attacker can intercept the plaintext communication to your domain used to show control over the domain and trivially obtain a certificate. If your threat model is adversarial nation states that control a CA or ten and are willing to create some bad issuance drama... again no security added by browser SSL. If your threat model is an attacker who will compromise your webserver because no one can keep up with the flood of new vulnerabilities, and the only way you can keep a private key private is to keep it offline-- which can't be used with SSL then again, no joy. Some people believe the use of HTTPS in these cases creates a false sense of security and reduces the likelyhood that people will check using other mechanisms. I am pretty confident() that they are wrong and that they've not actually measured the effect. But it's not a crazy position to take. (Especially when you mix in how easy it is for https snafus to result in giving users scary warnings that make them blind to scary warnings) (: confidence due to religiously verifying packages and keys, and finding _frequently_ that they are unverifiable even on major high profile targets like major linux distros or crypto libraries... e.g. signed with a key that is signed by no one else and exists only in the same directory as the binary; if people were actually checking I wouldn't find so many messed up cases; Also confident by watching the number of .sig downloads on my own software-- no one checks).
based2 10y ago
https://en.wikipedia.org/wiki/GOST_(block_cipher) https://en.wikipedia.org/wiki/GOST_(block_cipher)
meshko 10y ago
So if you encrypt your data with both only people who have access to backdoors from both sides will be able to decrypt it!
ex3ndr 10y ago
We are using in Actor.im double encryption of all our traffic with AES+Kuznechik and SHA256+Streebog. We are modified Signal protocol to handle such encryption. While keeping curve25519-only for public key cryptography as russia doesn't have any kind of standart for pki. Main ussue is performance. AES and SHA256 usually have hardware optimizations in ARM and x64 processors, but Russian doesn't have such thing. Second thing is i think that this is not actually required as AES and Kuznechik have very similar ideas in them with just slightly different combination. Also AES is not cracked and it is not going to be in the nearest future.
- stargrave 10y ago
  Maybe I misunderstood you, but http://www.cypherpunks.ru/gost/enVKO.html http://www.cypherpunks.ru/gost/enVKO.html VKO 34.10-2001 is ECDH analogue. It uses two 256 or 512-bit elliptic curves keypairs for deriving common shared 256-bit key. It is Diffie-Hellman, like curve25519, with at least 128-bit security margin. http://www.cypherpunks.ru/gost/en3410.html http://www.cypherpunks.ru/gost/en3410.html GOST R 34.10-2001/2012 are digital signatures based on elliptic curves. Just like ECDSA.
avodonosov 10y ago
GPL licensed Belarusian crypto standards implementation: https://github.com/bcrypto/bee2 https://github.com/bcrypto/bee2
mataug 10y ago
Its nearly impossible to predict when someone would find vulnerabilities (or if they have already in secret, Bletchley Park anyone) in crypto primitives and the problem gets compounded we try to use untested crypto primitives such as those highlighted in this article. AES has been around since 2001 and researchers haven't gotten past 7 of the 10 rounds so that significantly improves my confidence in its ability to not crumble under the most simple cryptanalysis. Here's an interesting video by the author of one of the attacks on the inner round of SHA-3 explaining why public analysis is exceptionally important. https://www.youtube.com/watch?v=uT4hrWkbBxM https://www.youtube.com/watch?v=uT4hrWkbBxM My point is that though gaining popularity may be good because more researchers may find vulnerabilities but until these primitives are proven its probably not a good idea to use then in any real world application.
pps43 10y ago
> they are obviously not worse, in some places are much better Not sure why it is obvious, especially after Alex Biryukov et al reverse engineered S-Boxes of Streebog and Kuznyechik [1]. If you suspect Dual_EC_DRBG kind of weakness, why not use some algorithm without magic constants like Speck [2]? [1] https://eprint.iacr.org/2016/071.pdf https://eprint.iacr.org/2016/071.pdf [2] http://eprint.iacr.org/2013/404.pdf http://eprint.iacr.org/2013/404.pdf

84 points by stargrave 10y ago

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

contingencies 10y ago

Some projects, such as Gentoo, use multiple hashing algorithms in parallel to protect against potential collision attacks while verifying package sources. Adding Streebog for diversity may be a good idea.

hannob 10y ago
Actually Gentoo stopped doing that. (Which imho is sane. It's useless overhead for a completely theoretical scenario that will never happen.)
- tptacek 10y ago
  It was very sane in the 1990s, when hash combiners were invented and designed by Paul Kocher into SSL 3.0. The hashes we had to work with then were basically first generation designs, preceding the first wave of major cryptanalytic results against hashes. An MD5/SHA1 hash combiner made sense. It is less sane now, I agree. With the possible exception of PQ schemes, cascades of all kinds are a silly idea.
  - hannob 10y ago
    Well, I'd say we can pretty clearly pinpoint when cascading schemes makes sense: When we have different algs with different security properties and we can't have them all in one algorithm then cascading makes sense. This is the case for newhope + x25519, because one is based on well known crypto, but not quantum safe, the other is based on not so well known crypto, but (maybe) quantum safe. You could make similar arguments in the past about hash functions when the analysis around their safety was much more fuzzy. (Which is why I can also understand why Gentoo decided way back to combine sha2+whirlpool.)
- contingencies 10y ago
  I think perhaps portage simply stopped winking ;-) at you while validating package sources on a per-algorithm basis. Typical Manifest file: DIST <filename> <size> SHA256 <sha256_checksum> SHA512 <sha512_checksum> WHIRLPOOL <whirlpool_checksum> Looks like SHA256, SHA512 + Whirlpool to me. Apparently the SHA algorithms have FIPS (US) and NESSIE (EU) certification. Whirlpool has NESSIE (EU) certification. Streebog has GOST (Russian) certification. Added https://bugs.gentoo.org/show_bug.cgi?id=597736 https://bugs.gentoo.org/show_bug.cgi?id=597736 for discussion.

tormeh 10y ago

So, if you encrypted a file with a NIST algorithm and then encrypted the resulting file again with a GOST one, would that make it secure?

kkl 10y ago
That is called a "cipher cascade"[1] and practically speaking, no. [1] https://en.wikipedia.org/wiki/Multiple_encryption https://en.wikipedia.org/wiki/Multiple_encryption
- code_sardaukar 10y ago
  I think you're missing the implication in the original comment, that the NSA has put a backdoor into NIST and the Russian equivalent has put a backdoor into GOST, but neither can use the other's backdoor.
  - ex3ndr 10y ago
    We have done double encryption based on same ideas.
    - tptacek 10y ago
      I cannot tell you how silly this is. If you're using GOST, you're no longer building NIST-compliant crypto. If you're using NIST, you're no longer building GOST-compliant crypto. For Christ's sake, just stop using standardized crypto if you're worried about backdoors like this. Use an eSTREAM portfolio cipher for bulk crypto, use Blake2 as your hash, and use Curve448 for key agreement and signatures. You can just use the Noise protocol framework to accomplish this, which was designed to use all of these components.
      - hueving 10y ago
        It's still NIST compliant crypto on the outside regardless of the inner contents. Assuming NIST(GOST(plaintext)), NIST would be terribly broken if using GOST ciphertext as the payload weakened the security. It's crypto 101 that, given a ciphertext without the key, an algorithm's correct input should be indistinguishable from random input of the same length. I'm shocked that you think the plaintext contents would have an affect on whether or not something is NIST compliant.

eternalban 10y ago

I don't get these crypto types that use plain http for the download page [1] and then make a show with "You have to verify downloaded tarballs integrity and authenticity to be sure that you retrieved trusted and untampered software." And if you go to the "alternate resources" links[2][3], you get "Error code: sec_error_cert_signature_algorithm_disabled." [1]: http://www.cypherpunks.ru/gogost/Download.html#Download http://www.cypherpunks.ru/gogost/Download.html#Download [2]: https://lists.cypherpunks.ru/mailman/listinfo/gost https://lists.cypherpunks.ru/mailman/listinfo/gost [3]: https://git.cypherpunks.ru/cgit.cgi/gogost.git/ https://git.cypherpunks.ru/cgit.cgi/gogost.git/

fulafel 10y ago
End-to-send security is much better than the in-flight protection TLS gets you, and even that only as far as you trust the half-assed pki. I imagine most crypto experts don't put much faith in the integrity of their hosting providers and are not in the business of opsec themselves. Of course end-to-end only helps if people actually perform the check... TL;DR They probably think TLS in software distribution = false sense of security.
stargrave 10y ago
PKI is a business model. That download page suggests you to verify downloaded tarballs with OpenPGP key, or visit Git repository to look for signed (OpenPGP again) tags there. Of course you have to setup some kind of trust for verifying keys. If your browser shows you such kind of errors, then seems that you do not trust CAcert.org used for certificate creation. You may retrieve OpenPGP keys and find signature you may trust. PKI (HTTPS) is single point of trust, OpenPGP provides much more ones.
- deleted 10y ago
  [deleted]
nullc 10y ago
If your primary threat model is an active attacker in proximity to the server, rather than the client, SSL provides _NO_ security: The attacker can intercept the plaintext communication to your domain used to show control over the domain and trivially obtain a certificate. If your threat model is adversarial nation states that control a CA or ten and are willing to create some bad issuance drama... again no security added by browser SSL. If your threat model is an attacker who will compromise your webserver because no one can keep up with the flood of new vulnerabilities, and the only way you can keep a private key private is to keep it offline-- which can't be used with SSL then again, no joy. Some people believe the use of HTTPS in these cases creates a false sense of security and reduces the likelyhood that people will check using other mechanisms. I am pretty confident() that they are wrong and that they've not actually measured the effect. But it's not a crazy position to take. (Especially when you mix in how easy it is for https snafus to result in giving users scary warnings that make them blind to scary warnings) (: confidence due to religiously verifying packages and keys, and finding _frequently_ that they are unverifiable even on major high profile targets like major linux distros or crypto libraries... e.g. signed with a key that is signed by no one else and exists only in the same directory as the binary; if people were actually checking I wouldn't find so many messed up cases; Also confident by watching the number of .sig downloads on my own software-- no one checks).

based2 10y ago

https://en.wikipedia.org/wiki/GOST_(block_cipher) https://en.wikipedia.org/wiki/GOST_(block_cipher)

meshko 10y ago

So if you encrypt your data with both only people who have access to backdoors from both sides will be able to decrypt it!

ex3ndr 10y ago

We are using in Actor.im double encryption of all our traffic with AES+Kuznechik and SHA256+Streebog. We are modified Signal protocol to handle such encryption. While keeping curve25519-only for public key cryptography as russia doesn't have any kind of standart for pki. Main ussue is performance. AES and SHA256 usually have hardware optimizations in ARM and x64 processors, but Russian doesn't have such thing. Second thing is i think that this is not actually required as AES and Kuznechik have very similar ideas in them with just slightly different combination. Also AES is not cracked and it is not going to be in the nearest future.

stargrave 10y ago
Maybe I misunderstood you, but http://www.cypherpunks.ru/gost/enVKO.html http://www.cypherpunks.ru/gost/enVKO.html VKO 34.10-2001 is ECDH analogue. It uses two 256 or 512-bit elliptic curves keypairs for deriving common shared 256-bit key. It is Diffie-Hellman, like curve25519, with at least 128-bit security margin. http://www.cypherpunks.ru/gost/en3410.html http://www.cypherpunks.ru/gost/en3410.html GOST R 34.10-2001/2012 are digital signatures based on elliptic curves. Just like ECDSA.

avodonosov 10y ago

GPL licensed Belarusian crypto standards implementation: https://github.com/bcrypto/bee2 https://github.com/bcrypto/bee2

mataug 10y ago

Its nearly impossible to predict when someone would find vulnerabilities (or if they have already in secret, Bletchley Park anyone) in crypto primitives and the problem gets compounded we try to use untested crypto primitives such as those highlighted in this article. AES has been around since 2001 and researchers haven't gotten past 7 of the 10 rounds so that significantly improves my confidence in its ability to not crumble under the most simple cryptanalysis. Here's an interesting video by the author of one of the attacks on the inner round of SHA-3 explaining why public analysis is exceptionally important. https://www.youtube.com/watch?v=uT4hrWkbBxM https://www.youtube.com/watch?v=uT4hrWkbBxM My point is that though gaining popularity may be good because more researchers may find vulnerabilities but until these primitives are proven its probably not a good idea to use then in any real world application.

pps43 10y ago

> they are obviously not worse, in some places are much better Not sure why it is obvious, especially after Alex Biryukov et al reverse engineered S-Boxes of Streebog and Kuznyechik [1]. If you suspect Dual_EC_DRBG kind of weakness, why not use some algorithm without magic constants like Speck [2]? [1] https://eprint.iacr.org/2016/071.pdf https://eprint.iacr.org/2016/071.pdf [2] http://eprint.iacr.org/2013/404.pdf http://eprint.iacr.org/2013/404.pdf