summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/ecdsa
diff options
context:
space:
mode:
authortb <>2023-03-04 21:30:23 +0000
committertb <>2023-03-04 21:30:23 +0000
commitf5af461be23ab6e7a4a998f974edf286d18cac7c (patch)
treed779180f7a5713ad27d6a694abfdddc34dd2ce53 /src/lib/libcrypto/ecdsa
parent73e44beee499b22262049c3d41e658d53f9808ad (diff)
downloadopenbsd-f5af461be23ab6e7a4a998f974edf286d18cac7c.tar.gz
openbsd-f5af461be23ab6e7a4a998f974edf286d18cac7c.tar.bz2
openbsd-f5af461be23ab6e7a4a998f974edf286d18cac7c.zip
Cap the number of iterations in DSA signing
The DSA standard specifies an infinite loop: if either r or s is zero in the signature calculation, a new random number k shall be generated and the whole thing is to be redone. The rationale is that, as the standard puts it, "[i]t is extremely unlikely that r = 0 or s = 0 if signatures are generated properly." The problem is... There is no cheap way to know that the DSA domain parameters we are handed are actually DSA domain parameters, so even if all our calculations are carefully done to do all the checks needed, we cannot know if we generate the signatures properly. For this we would need to do two primality checks as well as various congruences and divisibility properties. Doing this easily leads to DoS, so nobody does it. Unfortunately, it is relatively easy to generate parameters that pass all sorts of sanity checks and will always compute s = 0 since g is nilpotent. Thus, as unlikely as it is, if we are in the mathematical model, in practice it is very possible to ensure that s = 0. Read David Benjamin's glorious commit message for more information https://boringssl-review.googlesource.com/c/boringssl/+/57228 Thanks to Guido Vranken for reporting this issue, also thanks to Hanno Boeck who apparently found and reported similar problems earlier. ok beck jsing
Diffstat (limited to 'src/lib/libcrypto/ecdsa')
0 files changed, 0 insertions, 0 deletions