[gnutls-devel] GnuTLS | GOST key exchange support (!1097)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Thu Nov 7 11:28:05 CET 2019

Nikos Mavrogiannopoulos commented on a discussion on lib/auth/vko_gost.c: https://gitlab.com/gnutls/gnutls/merge_requests/1097#note_241321055

> +		goto cleanup;
> +	}
> +
> +	if (info != NULL && info->ncerts != 0) {
> +		ret = _gnutls_get_auth_info_pcert(&peer_cert,
> +				session->security_parameters.
> +				server_ctype, info);
> +
> +		if (ret < 0) {
> +			gnutls_assert();
> +			goto cleanup;
> +		}
> +
> +		has_pcert = 1;
> +	}
> +

There is `gnutls_memcmp` for it. However going through `_gnutls_gost_keytrans_decrypt`, it is possible to distinguish with timing the ukm comparison failure vs the key unwrap failure. The key transport as per RSA is an oracle itself which allows anyone (client) to send arbitrary data to the server and time its results or try many inputs until something succeeds and that help the attacker to deduce something about the key. I do not know the particulars of this key exchange but it looks like something risky to add or enable by default (in gost or non-gost setup).

As I do not know the algorithm, I do not have an attack, but only hints that such thing may exist. Are there public papers on this algorithm that describe its resistance to RSA-style bleichenbacher oracle attacks? What I'm trying to avoid here is a big rewrite in the future like we did for the RSA.

Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/1097#note_241321055
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/20191107/a456f111/attachment.html>

More information about the Gnutls-devel mailing list