[gnutls-devel] GnuTLS | Clarify plans for gost implementation (#942)

[Development of GNU's TLS library]

Dmitry Baryshkov commented:


So, are you afraid of unknown S-Box origins, of rogue CAs or of cheburnet? I see FUD rather than technical arguments, sorry to say that.

I really dislike this kind of conversation. Open Source Software was always about providing a possibility, rather than policy. By adding support for GOST cipher/hash/dsa into OSS projects we fill the niche of proprietary softwares for users, which do not have to use certified solution.

GOST 28147-89 is getting replaced by it's variant Magma (with fixed S-BOX) and 128-bit cipher Kuznyechik. See GOST R 34.12-2015 / GOST 34.12-2018. And no, as far as I understand there is no law that you have described. Could you please point me to it?

My primary target for GOST was to support pkcs#7 signatures, because they are heavily used in Russia. Next target is TLS, because more and more sites are going to use it (Yandex, Mail.ru have plans for using it).

In GnuTLS there is a `--disable-gost` option that completely disables all GOST algorithms. Also one can use crypto policies to disable GOST. Next major version of GnuTLS will have GOST R 34.11-94 marked as unsuitable for signature verification. I do not think there is anything else to add, unless you can provide actual relevant research papers demonstrating vulnerabilities.

For the Nettle library Niels has expressed that he would like to keep binary compatibility by not disabling any algorithms (even known to be broken).

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/942#note_292428584
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200221/798fbe52/attachment.html>