Hanno Böck created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1747
ECDSA private key values should be stored in a bytestring of fixed-length with the size of the modulus (see RFC 5915 [1]). This also mitigates possible sidechannels that may leak information about leading zeros when loading a private key (see also [2]). It appears gnutls encodes the private d value with an additional zero if the upmost bit of the d value is set (~1/2 of keys). It encodes d with a byte too small if the top 9 bits are zero. (happens in 1/512 of keys). To test, generate a large number of ecdsa keys: ``` for x in $(seq 1 1000); do certtool --generate-privkey --outfile $x.key --key-type ecdsa --outder; done ``` Given the fixed-size encoding, all private keys with the same curve should have the same size, but they differ. Some are 121 bytes (correctly encoded), some 122 bytes, some (few) 120 bytes. Here's a python script that checks if ECDSA's d has the correct encoding size: https://github.com/hannob/tlshelpers/blob/main/checkkeyenc Given this can lead to a timing sidechannel leaking (very limited) information about the private key, one may see this as a security issue. However, the risk is very low and probably not practically relevant, as the information that can be leaked is extremely limited. [1] https://www.rfc-editor.org/rfc/rfc5915.html#section-3 [2] https://seclists.org/oss-sec/2025/q4/38 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1747 You're receiving this email because of your account on gitlab.com.
_______________________________________________ Gnutls-devel mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-devel
