GOST cryptography – Russian Federation’s cryptographic algorithms
cypherpunks.ru
cypherpunks.ru
[1]: http://www.cypherpunks.ru/gogost/Download.html#Download
TL;DR They probably think TLS in software distribution = false sense of security.
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).
Could you explain? Are you talking about DNS spoofing / hijacking or protocol downgrade attacks? There are answers to those, so I'm not following.
> 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.
If you are important enough to worry about 0days, then you need to invest heavily in monitoring and tools like Appcanary that can autoupdate your packages. If you detect that your key is compromised then issue a new one and move on with your life.
HTTPS does not create a false sense of security, MD5 sums for packages delivered over non-TLS do. HTTPS isn't perfect but not using it because it won't stop some very well funded actors is silly. I'm worried about hacked wifi routers at my cafe, not about state level actors stealing HTTPS certificates.
When using PGP, you have to decide how much you trust each key. All that PGP does is enforce your trust preferences.
Moreover how can you "transfer" the trust to other people? If you proxy/give tarball to someone else, then how can you prove that you did not tamper it? Again, with detached signatures people knowing public key can authenticate it, without connecting to Internet. With TLS there is only single distribution point (TLS website) that can not transfer trust to someone else.
What CA should be used for certificate issuing? Paid one? Not an option if you do not want to support PKI business model (it is business, not security). CAcert.org? Modern browsers and operating systems does not include its certificate too. So anyway you have to get its public key too somehow.
So, TLS has the same problem of getting the public key and is less convenient in use, requiring TLS-aware webserver (instead of cheap providers with static pages hosting), without ability to transfer trust (send signature separately) to someone else. OpenPGP keys (for www.cypherpunks.ru websites), comparing to CA ones, can be received with several (!) keyservers (many of them replicates between themselves), several (!) DNS servers (listed as NS record), through various transports (VPN, proxy, Tor) to one of webservers (listed as A/AAAA record).
They are using a SHA-512 signature in the certificate, which seems to be quite uncommon, but maybe that's why they did it...
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 for discussion.
Yes, that's paranoid, but if the price of being safe from paranoid outcomes is dropping $0.02 in a change jar, I'm willing to pay.
And by the way, these Gentoo manifests, if you're worried about their cryptographic security there's something much bigger to worry about: For most users they're transmitted unprotected and unsigned via rsync. There are non-default ways to improve that, but the default is insecure. (It pains me to say this, because I'm a long time Gentoo dev, but it's a nasty truth about Gentoo's lack of security.)
If you want to improve Gentoo's cryptographic integrity this is the first thing that should be worked on (either through a working signing system that would be acceptable by default or by switching to an authenticated transmission mechanism like git over https). This would be much more helpful than adding an obscure hash algorithm.
# emerge-webrsync
Fetching most recent snapshot ...
Trying to retrieve 20161021 snapshot from http://mirror.com/gentoo ...
Fetching file portage-20161021.tar.xz.md5sum ...
Fetching file portage-20161021.tar.xz.gpgsig ...
Fetching file portage-20161021.tar.xz ...
(Edit: WTF! Either past-midnight has zapped my brain, or this is a total community pants down moment. emerge-webrsync doesn't actually verify the GPG signature by default, despite downloading it, and no warning is issued! One must follow the obtuse, well-buried instructions @ https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features... to get it to actually verify ... I've added another bug @ https://bugs.gentoo.org/show_bug.cgi?id=597800 about this... serious misfeature! Looks like for all intents and purposes if you want to own the average Gentoo box, having MITM on sync + emerge is enough! NSA must have been using that...)
It is less sane now, I agree. With the possible exception of PQ schemes, cascades of all kinds are a silly idea.
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.)
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.
http://www.cypherpunks.ru/gost/en3410.html GOST R 34.10-2001/2012 are digital signatures based on elliptic curves. Just like ECDSA.
You can just use the Noise protocol framework to accomplish this, which was designed to use all of these components.
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.
I am making a very simple point. If you don't trust NIST standards because you think they're backdoored, but won't run Russian standards because you think they might be too, the answer isn't to compose the two flawed standards.
Instead: just use a crypto stack composed of well-reviewed, well-regarded components that are neither NIST nor GOST standards.
Nobody in the world thinks Curve25519 is backdoored, or that Chapoly is, or that Blake2 is.
In fact: this is what I think you should do anyways. Maybe, just maybe, you should keep using AES because it will be more performant --- but the cycles/byte cost of bulk encryption is so low that I'm skeptical that this matters. Otherwise: avoid crypto standards like NIST and GOST. Standards processes produce crypto that is at best ungainly and at worst actively harmful. Standards are evil.
I am, of course, addressing this advice to the very, very limited subset of engineers who should be working with crypto directly. Everyone else should just use Nacl.
It's the same thing as having 3 computers vote on the space shuttle control signals. You could follow your argument and claim, "If the software has a bug in it that would produce output different from the other 2, then don't use it!" The problem is that we don't know if there is an issue or not, so we go the safer route with multiple implementations.
You also did not address the main issue I have with your comment. You made this assertion: "If you're using GOST, you're no longer building NIST-compliant crypto.", which implies that the contents of the plaintext determine if the crypto is NIST compliant. This is completely false.
It's like claiming that uploading an AES encrypted file over an HTTPS connection is less secure than uploading via HTTP.
The point is again simple: there are far better options to untrustworthy standards than composing them in the hopes of mitigating their flaws. It's for the same reason that we used to use hash combiners to handle MD5 and SHA1, but now we use HKDF over SHA-2.
Nearly every secure system I've dealt with (in the military side) encrypted at the network layer (VPN) and they sent encrypted files over that channel.
That doesn't mean that redundant clientside encryption of files is a sensible feature for a secure channel to have.
That said, the NSA recommends multiple encryption, for instance using "inner" and "outer" VPN gateways:
https://www.nsa.gov/resources/everyone/csfc/capability-packa...
This sort of thing should be standard protocol for critical infrastructure, such as water supply, power grid and healthcare systems.
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
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.
Is there a reason these algorithms aren't formally introduced as NIST standards? Are they copyrighted? Couldn't anyone submit them?
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.
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/
[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.
Btw, there is no requirement for NIST algs to be US-based. E.g. AES was developed in Belgium.
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.
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
* 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.
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.
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]?