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

[Development of GNU's TLS library]

Dmitry Baryshkov commented:


So, how does certification of proprietary software correlate to open source projects? They will never be certified, believe me. Even OpenSSL's gost engine (developed by CryptoCom) can not be certified. This is the significant difference from FIPS certification (where one can certify software after it has been developed).

To repeat one of my previous messages: a list of s-boxes supported for key transport, for CMS files, for TLS key exchange is fixed. They are present in RFC 4357 and RFC 7836. There is no guarantee that proprietary software will support any other S-BOX, so one can not use them to encrypt data in these cases. And strictly speaking I do not care about other users of gost28147 algorithm. If you do not believe in RFCs, you can resort to reading "recommendation for standardization", "methodical recommendations" and "technical specifications" developed together by GOST's technical committee 26, CryptoPro, InfoTeCS, CryptoCom and other proprietary software vendors.

Niels was talking about binary compatibility between Nettle builds, if I got him right. On top of that support for GOST R 34.11-94 hash algorithm was added in Nettle 2.6. So Nettle contained gost28147 code for ages.

So far we are discussing Nettle on GnuTLS's issue board, which does not seem logical to me. Maybe this discussion should be continued on nettle-bugs ML?

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