A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 2025-05-10T05:54:39+00:00 2025-05-10T05:54:39+00:00 tb 2025-05-10T05:54:39+00:00 urn:sha1:41e8f99dd1625a9f0c80ce9d4383e95b18e85709 ok jsing 2024-05-11T06:43:50+00:00 tb 2024-05-11T06:43:50+00:00 urn:sha1:d65dad3857706a874393df2d73159b69e36efaf6 There are no accessors to set them, so this has been involved in a bunch of dead logic ever since we made DSA opaque a few years ago. ok jsing 2024-05-09T20:57:49+00:00 tb 2024-05-09T20:57:49+00:00 urn:sha1:ffc65ff3f261383cb9eb7a1473b4bb4db066fea5 2024-05-09T20:56:52+00:00 tb 2024-05-09T20:56:52+00:00 urn:sha1:21de27a87e49167d85c8177dae011f3847c26066 no functional change 2023-08-03T18:53:56+00:00 tb 2023-08-03T18:53:56+00:00 urn:sha1:44ff07e01874ea8be0c72bf9d20cb7f13b76cca8 Provide bn_rand_in_range() which is a slightly tweaked version of what was previously called bn_rand_range(). The way bn_rand_range() is called in libcrypto, the lower bound is always expressible as a word. In fact, most of the time it is 1, the DH code uses a 2, the MR tests in BPSW use 3 and an exceptinally high number appears in the Tonelli-Shanks implementation where we use 32. Converting these lower bounds to BIGNUMs on the call site is annoying so let bn_rand_interval() do that internally and route that through bn_rand_in_range(). This way we can avoid using BN_sub_word(). Adjust the bn_isqrt() test to use bn_rand_in_range() since that's the only caller that uses actual BIGNUMs as lower bounds. ok jsing 2023-07-08T14:28:15+00:00 beck 2023-07-08T14:28:15+00:00 urn:sha1:ed57ee23c30661b8054a17346a8e19be71fd9ede ok tb@ 2023-03-27T10:25:02+00:00 tb 2023-03-27T10:25:02+00:00 urn:sha1:aeb32cad44c92f3786167b06a0f9c4310cbb713d ok jsing 2023-03-04T21:30:23+00:00 tb 2023-03-04T21:30:23+00:00 urn:sha1:0b0f128bcf324942bdf04b0afe8df296e9d7abc9 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 2023-03-04T21:06:17+00:00 tb 2023-03-04T21:06:17+00:00 urn:sha1:01b0ce78c17d3cb0caa4b9c31942bcfbcebc6c7d We already had some checks on both sides, but they were less precise and differed between the functions. The code here is messy enough, so any simplification is helpful... ok beck jsing 2023-02-13T09:21:35+00:00 tb 2023-02-13T09:21:35+00:00 urn:sha1:c0901cb4aef7ee8681b9f6f5a9ac897e1aa4dd5e discussed with jsing