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

[Development of GNU's TLS library]

Andrew Aladjev commented:


> So, are you afraid of unknown S-Box origins, of rogue CAs or of cheburnet?

I am answering questions about usage. Usage is awful and this is not my fault. There are nothing to be afraid of.

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

Nobody is going to break this possibility. You can merge any kind of algorithms with option for enable/disable it and everybody will be happy. But you have merged it into nettle as it is and I am sure that it is not acceptable.

> 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?

Licensing process of any cryptosystem by russian federal agency requires usage of completely proprietary gost system without ability to change it. Federal agency resolves what s-boxes you will use, not RFC. There is a [large list of activities](http://clsz.fsb.ru/license.htm) that requires licensing and this is not only about state secrets.

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

I see no problem here. Russian government already signed law about mandatory installation of russian software on any electronic device. One of the most important requirement is gost support. You will enable gost and prepare binary release for installation. Yandex already created special web browser with gost support. But yandex is not going to force enabling of gost all over the world.

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

I have no complains about gnutls. I have complain about nettle, because not only gnutls depends on nettle. I want to be able to disable gost support in nettle in the easy way.

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

Binary compatibility won't be broken without gost, because there was no nettle release with gost support yet. Nothing will be changed if gost will be disabled by default.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/942#note_292475238
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/d7e988ab/attachment.html>