<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openbsd/src/lib/libcrypto/dsa, branch OPENBSD_7_3_BASE</title>
<subtitle>A mirror of https://github.com/libressl/openbsd.git
</subtitle>
<id>https://git.lua4.win/openbsd/atom?h=OPENBSD_7_3_BASE</id>
<link rel='self' href='https://git.lua4.win/openbsd/atom?h=OPENBSD_7_3_BASE'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/'/>
<updated>2023-03-11T15:29:03+00:00</updated>
<entry>
<title>Fix an off-by-one in dsa_check_key()</title>
<updated>2023-03-11T15:29:03+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-11T15:29:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=b402f35d1e79e0a473421c7a9de69d6227f38d7e'/>
<id>urn:sha1:b402f35d1e79e0a473421c7a9de69d6227f38d7e</id>
<content type='text'>
The private key is a random number in [1, q-1], so 1 must be allowed.
Since q is at least an 160-bit prime and 2^159 + 1 is not prime (159
is not a power of 2), the probability that this is hit is &lt; 2^-159,
but a tiny little bit wrong is still wrong.

Found while investigating a report by bluhm
ok jsing
</content>
</entry>
<entry>
<title>Call BN_free() instead of BN_clear_free().</title>
<updated>2023-03-07T09:27:10+00:00</updated>
<author>
<name>jsing</name>
<email></email>
</author>
<published>2023-03-07T09:27:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=19dfe7f484e5739359ee8c102d879d125df916ad'/>
<id>urn:sha1:19dfe7f484e5739359ee8c102d879d125df916ad</id>
<content type='text'>
BN_clear_free() is a wrapper that calls BN_free() - call BN_free() directly
instead.

ok tb@
</content>
</entry>
<entry>
<title>Simplify the consistency checks in old_dsa_priv_decode()</title>
<updated>2023-03-04T21:42:49+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T21:42:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=1365d3058017df2eab801fdaff293922ee0032a8'/>
<id>urn:sha1:1365d3058017df2eab801fdaff293922ee0032a8</id>
<content type='text'>
We have long had expensive checks for DSA domain parameters in
old_dsa_priv_decode(). These were implemented in a more complicated
way than necesary.

ok beck jsing
</content>
</entry>
<entry>
<title>Cap the number of iterations in DSA signing</title>
<updated>2023-03-04T21:30:23+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T21:30:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=0b0f128bcf324942bdf04b0afe8df296e9d7abc9'/>
<id>urn:sha1:0b0f128bcf324942bdf04b0afe8df296e9d7abc9</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Small readability tweak in old_dsa_priv_decode()</title>
<updated>2023-03-04T21:08:14+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T21:08:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=5b21203ce56441bf02442a9dbc57d44a0a558cf3'/>
<id>urn:sha1:5b21203ce56441bf02442a9dbc57d44a0a558cf3</id>
<content type='text'>
Explicitly check against NULL and turn early return into goto err.

ok beck jsing
</content>
</entry>
<entry>
<title>Call dsa_check_keys() before signing or verifying</title>
<updated>2023-03-04T21:06:17+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T21:06:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=01b0ce78c17d3cb0caa4b9c31942bcfbcebc6c7d'/>
<id>urn:sha1:01b0ce78c17d3cb0caa4b9c31942bcfbcebc6c7d</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Add dsa_check_key() calls on DSA decoding</title>
<updated>2023-03-04T21:02:21+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T21:02:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=7087a91a87fa4d6c5a301533b0bbfdb32632cda9'/>
<id>urn:sha1:7087a91a87fa4d6c5a301533b0bbfdb32632cda9</id>
<content type='text'>
When decoding a public or a private key, use dsa_check_key() to ensure
consistency of the DSA parameters. We do not always have sufficient
information to do that, so this is not always possible.

This adds new checks and replaces incomplete existing ones. On decoding
the private key we will now only calculate the corresponding public key,
if the sizes are sensible. This avoids potentially expensive operations.

ok beck jsing
</content>
</entry>
<entry>
<title>Provide dsa_check_key()</title>
<updated>2023-03-04T20:54:52+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T20:54:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=990d95a448bfa7728c50a299c62b3fcbfe57d9eb'/>
<id>urn:sha1:990d95a448bfa7728c50a299c62b3fcbfe57d9eb</id>
<content type='text'>
This is a cheap check that ensures basid parameter consistency per
FIPS 186-4: 1 &lt; g &lt; q, that q has the allowed bit sizes 160, 224, 256
and that p is neither too small nor too large. Unfortunately, enforcing
the three allowed sizes for p is not possible since the default dsa key
generation has not respected this limitation.

Instead of checking that p and q are prime, we only check that they
are odd. Check that public and private keys, if set, are in the proper
range. In particular, disallow zero values.

Various versions of these checks have been added to the dsa code
over time. This consolidates and extends them and in a subsequent
commit wewill replace the incomplete checks. BoringSSL has a similar
function of the same name, thanks to David Benjamin for pointing it
out.

ok beck jsing
</content>
</entry>
<entry>
<title>Provide DSA_R_INVALID_PARAMETERS error code</title>
<updated>2023-03-04T20:47:04+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-03-04T20:47:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=82dda41e0d08799a2a3e1c9de816ee1c4bea6851'/>
<id>urn:sha1:82dda41e0d08799a2a3e1c9de816ee1c4bea6851</id>
<content type='text'>
This has been missing for a while already and will be used in a
few upcoming commits.

ok beck jsing
</content>
</entry>
<entry>
<title>Merge dsa_sign.c and dsa_vrf.c into dsa_ossl.c</title>
<updated>2023-02-13T09:21:35+00:00</updated>
<author>
<name>tb</name>
<email></email>
</author>
<published>2023-02-13T09:21:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/openbsd/commit/?id=c0901cb4aef7ee8681b9f6f5a9ac897e1aa4dd5e'/>
<id>urn:sha1:c0901cb4aef7ee8681b9f6f5a9ac897e1aa4dd5e</id>
<content type='text'>
discussed with jsing
</content>
</entry>
</feed>
