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."<p>[1]: <a href="http://www.cypherpunks.ru/gogost/Download.html#Download" rel="nofollow">http://www.cypherpunks.ru/gogost/Download.html#Download</a><p>[2]: <a href="https://lists.cypherpunks.ru/mailman/listinfo/gost" rel="nofollow">https://lists.cypherpunks.ru/mailman/listinfo/gost</a><p>[3]: <a href="https://git.cypherpunks.ru/cgit.cgi/gogost.git/" rel="nofollow">https://git.cypherpunks.ru/cgit.cgi/gogost.git/</a>
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.
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.<p>Main ussue is performance. AES and SHA256 usually have hardware optimizations in ARM and x64 processors, but Russian doesn't have such thing.<p>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.
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.<p>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.<p>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.
<a href="https://www.youtube.com/watch?v=uT4hrWkbBxM" rel="nofollow">https://www.youtube.com/watch?v=uT4hrWkbBxM</a><p>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.
> "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."<p>Is there a reason these algorithms aren't formally introduced as NIST standards? Are they copyrighted? Couldn't anyone submit them?
> they are obviously not worse, in some places are much better<p>Not sure why it is obvious, especially after Alex Biryukov et al reverse engineered S-Boxes of Streebog and Kuznyechik [1].<p>If you suspect Dual_EC_DRBG kind of weakness, why not use some algorithm without magic constants like Speck [2]?<p>[1] <a href="https://eprint.iacr.org/2016/071.pdf" rel="nofollow">https://eprint.iacr.org/2016/071.pdf</a><p>[2] <a href="http://eprint.iacr.org/2013/404.pdf" rel="nofollow">http://eprint.iacr.org/2013/404.pdf</a>