From: David Woodhouse Date: Tue, 27 Jul 2021 13:47:42 +0000 (+0100) Subject: Fix RSA-PSS padding with SHA384 for TPMv2 keys X-Git-Tag: v8.20~78 X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=24ffd7b01f2e6e15dcbd7e591a141cedb9763d79;p=users%2Fdwmw2%2Fopenconnect.git Fix RSA-PSS padding with SHA384 for TPMv2 keys There seems to be a GnuTLS bug which was breaking SHA384 support. Work around it by destroying the hash context and making a fresh one. Signed-off-by: David Woodhouse --- diff --git a/gnutls_tpm2.c b/gnutls_tpm2.c index 5e1d7b4c..30bc674d 100644 --- a/gnutls_tpm2.c +++ b/gnutls_tpm2.c @@ -491,7 +491,19 @@ static int oc_pss_mgf1_pad(struct openconnect_info *vpninfo, gnutls_digest_algor emBuf[emLen - 1] = 0xbc; - /* Now the MGF1 function as definsed in RFC3447 Appendix B, although + /* Although gnutls_hash_output() is supposed to reset the context, + * it doesn't actually seem to work at least for SHA384; the later + * gnutls_hash_copy() ends up wrong somehow, and gives incorrect + * output. Unless we completely destroy the context and make a + * new one. https://gitlab.com/gnutls/gnutls/-/issues/1257 */ + gnutls_hash_deinit(hashctx, NULL); + err = gnutls_hash_init(&hashctx, dig); + if (err) { + hashctx = NULL; + goto out; + } + + /* Now the MGF1 function as defined in RFC3447 Appendix B, although * it's somewhat easier to read in NIST SP 800-56B §7.2.2.2. * * We repeatedly hash (M' || C) where C is an incrementing 32-bit