Re: DSA signatures in OpenSSL 3.0

[Richard Dymond]

On Mon, 14 Mar 2022 at 11:03, Tomas Mraz  wrote:

> On Mon, 2022-03-14 at 08:58 -0300, Richard Dymond wrote:
> > By the way, the reason I need to get the 'r' and 's' values from the
> > DSA signature is that I am encoding them one after the other as 160-
> > bit unsigned integers, in network byte order, as required by SSH and
> > described in section 6.6 of RFC 4253 (dss_signature_blob)[1]. To do
> > this encoding I am calling BN_bn2bin() twice to write 'r' followed by
> > 's' at the appropriate locations in a 40-byte buffer. By any chance,
> > does OpenSSL 3.0 provide any support for encoding a DSA signature
> > like this from a DSA_SIG (i.e. without having to extract 'r' and 's'
> > first and then use BN_bn2bin())?
>
> No, there is no such function. However there is not much overhead in
> doing the two BN_bn2bin calls (should those be BN_bn2binpad actually?)
> once you already have a DSA_SIG object.
>

OK, I suppose that was hoping for too much. But thanks for the tip
regarding BN_bn2binpad v. BN_bn2bin - that does simplify the code a little
more.

Richard

Re: DSA signatures in OpenSSL 3.0

[Richard Dymond]

On Mon, 14 Mar 2022 at 04:52, Tomas Mraz  wrote:

> The DSA_SIG_* functions are not deprecated including the i2d and d2i
> functions. So you can use d2i_DSA_SIG to decode the DER produced by the
> EVP_DigestSign() and then obtain the r and s values from the DSA_SIG.
>

Thank you, that works! For some reason it had escaped my notice that the
DSA_SIG_* functions are not deprecated.

By the way, the reason I need to get the 'r' and 's' values from the DSA
signature is that I am encoding them one after the other as 160-bit
unsigned integers, in network byte order, as required by SSH and described
in section 6.6 of RFC 4253 (dss_signature_blob)[1]. To do this encoding I
am calling BN_bn2bin() twice to write 'r' followed by 's' at the
appropriate locations in a 40-byte buffer. By any chance, does OpenSSL 3.0
provide any support for encoding a DSA signature like this from a DSA_SIG
(i.e. without having to extract 'r' and 's' first and then use BN_bn2bin())?

Richard

[1] https://datatracker.ietf.org/doc/html/rfc4253#section-6.6

DSA signatures in OpenSSL 3.0

[Richard Dymond]

Hi

I recently migrated an application from OpenSSL 1.1.1 to OpenSSL 3.0, and
I'm wondering how best to handle DSA signatures - specifically, the 'r' and
's' values - in OpenSSL 3.0.

In OpenSSL 1.1.1, it was pretty easy:

DSA_do_sign() - gets you a DSA_SIG
DSA_SIG_get0() - gets you the 'r' and 's' values from the DSA_SIG

This still works in OpenSSL 3.0, but the DSA_* functions are deprecated,
and so to avoid that I'm doing this instead:

EVP_DIgestSign() - gets you a DER-encoded signature blob
BN_bin2bn() - grabs 'r' or 's' from the signature blob, so long as you
point it at the right place in the blob

Which seems very cumbersome, and requires intimate knowledge of the layout
of the signature blob.

Is there a better way to get the 'r' and 's' values from a DSA signature in
OpenSSL 3.0 without using deprecated functions?

Thanks.

Richard

Re: OpenSSL 3.0 FIPS module configuration file

[Richard Dymond]

On Tue, 15 Feb 2022 at 09:53, Tomas Mraz  wrote:

> Please note that there are two checksums in the configuration file. One
> of them is the FIPS module checksum and the other is the checksum of
> the configuration. You can copy the file across machines if it is
> without the configuration checksum - that means the selftest will be
> always run when the FIPS module (i.e., the fips provider) is loaded.
>

Thanks for the info! I was wondering whether there was a FIPS-compliant way
to use fips.dll on a machine without first having to run 'openssl
fipsinstall' on that machine, and this seems to be it.

Richard

OpenSSL 3.0 FIPS module configuration file

[Richard Dymond]

Hi

Probably a dumb question, but why must the FIPS module configuration file
for OpenSSL 3.0 be generated on every machine that it is to be used on
(i.e. must not be copied from one machine to another)?

I just ran 'openssl fipsinstall' on two different machines with the same
FIPS module and it produced exactly the same output each time, so
presumably the reason has nothing to do with the config file being unique
to the machine.

Does it have something to do with the FIPS standard itself?

Richard