On 11/1/21 14:07, Justus Winter wrote:
Neal Gompa <ngomp...@gmail.com> writes:
On Thu, Oct 28, 2021 at 11:17 AM Justus Winter <jus...@sequoia-pgp.org> wrote:
Panu Matilainen <pmati...@redhat.com> writes:
https://tests.sequoia-pgp.org/rpmsop.html#Detached_Sign-Verify_roundtrip_with_key__Bob___MD5
- accepts MD5 signatures !!!
https://tests.sequoia-pgp.org/rpmsop.html#Signature_over_the_shattered_collision
- accepts SHA1 signatures !!!
Rpm needs to be able to work with content from the nineties, when MD5
was still the hottest thing around, ditto with SHA1.
Contemporary versions of RPM need to work with content from the
nineties? I find that hard to believe.
I still sometimes deal with RPMs created in the early 2000s, it's not
terribly hard to believe people wind up working with older stuff. Lots
of old Linux games were released as RPMs back in the 90s too.
I see. But, that doesn't mean that the RPMs are signed, or that the
signer's key is trusted by you, or that the signer's key uses a public
key signing algorithm and key size that is still cryptographically
relevant today.
I'm of the firm belief that signatures with weak hash algorithms should
be considered either bad or non-existent, and explicit override by the
administrator should be necessary to override that.
FWIW, non-existence is how rpm treats such things when encountered, such
as in FIPS mode.
In the pull request, Panu writes:
I'm saying that deciding what is an acceptable algorithm and what is
not, is a question that does not belong to rpm at all. It's a matter
of distro/system policies, including but not limited to FIPS
I'm worried about that. First of all, considering signatures using MD5
or SHA1 bad is not a policy, that is baseline footgun protection. Any
distro policy should be on top of that, i.e. a refinement.
I'm not arguing that MD5 or SHA1 is a secure algorithm by now, it's just
that questions like "what is and what is not a secure algorithm" leads
into the kind of political crap that I simply refuse to touch in rpm.
This is just a side-track of the agenda at hand, now can we please just
agree to disagree and move on.
Also, I don't quite understand how this policy is enabled or enforced.
As far as I can see, you defer the decision on what algorithm is
acceptable to the cryptographic backend.
Yes.
First, RPM makes no effort to put either openssl nor gcrypt into FIPS
mode, so it has to be a distro-wide or system wide configuration.
It's not RPM's business to configure such a thing even if it could! It's
a system policy that somebody needs to set, and rpm will happily comply.
https://www.gnupg.org/documentation/manuals/gcrypt/Enabling-FIPS-mode.html
https://wiki.openssl.org/index.php/FIPS_mode_set()
System-wide FIPS mode is not enabled by default on Fedora 35 or Debian
Bullseye.
I've only been using FIPS mode as an example of a policy that does
enforce obsolete hashes not getting used. FIPS is a whole lot more
though, it's not something the average user will want to have enabled.
My point is that there are mechanisms to deal with this on central
level, and that's where it should be handled. If MD5 is considered
insecure then disable the damn thing in the crypto library, and rpm will
merrily comply.
Second, OpenPGP separates digest computation and signature verification
into two steps. When RPM hands off the digest to the cryptographic
library, then the library doesn't have enough context to understand
which hash algorithm produced the digest (with the exception of RSA
signature verification, where the hash algorithm is passed along with
the digest).
Therefore, whether a hash algorithm is accepted for signature
verification comes down to whether it is produced by the backend or
not. I wrote a small test program to explore this.
This is the result on Fedora 35:
[liveuser@localhost-live ~]$ ./fipstest
gcrypt allows MD5
gcrypt allows SHA1
WARN: The current version of OpenSSL is not FIPS-capable.
openssl has MD5
openssl has SHA1
openssl allows SHA1
[liveuser@localhost-live ~]$ ./fipstest enable fips mode please
gcrypt allows MD5
gcrypt allows SHA1
WARN: The current version of OpenSSL is not FIPS-capable.
openssl has MD5
openssl has SHA1
openssl allows SHA1
This is the result on Debian Bullseye:
% ./fipstest
gcrypt allows MD5
gcrypt allows SHA1
openssl has MD5
openssl allows MD5
openssl has SHA1
openssl allows SHA1
% ./fipstest fips mode please
WARN: The current version of OpenSSL is not FIPS-capable.
WARN: Failed to get openssl into FIPS mode
gcrypt allows MD5
gcrypt allows SHA1
openssl has MD5
openssl allows MD5
openssl has SHA1
openssl allows SHA1
Some observations:
- On both systems, FIPS mode has no influence on the availability of
MD5 or SHA1 in gcrypt or openssl.
I've no idea whether FIPS is supposed to work on either. I only know it
from RHEL business where eg on RHEL 8, both MD5 and SHA1 are disabled
entirely.
- Fedora seems to have patched openssl to unconditionally disable MD5.
- On Fedora, RPM links against openssl, on Debian against gcrypt.
Based on these observations, I conclude that ---unless I missed a
different mechanism that enforces a different policy---
- on Fedora, RPM accepts SHA1 signatures
- on Debian, RPM accepts MD5 and SHA1 signatures
independent of whether FIPS mode is enabled, and that applies both for
signatures over data (i.e. RPM authentication) and binding signatures
(i.e. OpenPGP certificate canonicalization).
I'm blissfully unaware of the crypto configuration details of distros,
but if Fedora disables MD5 then that'd be a fine example of how I think
this all should work. Wiring these insecure algorithms time and time and
time and time and time after time into each individual program just
doesn't fly.
- Panu -
Even though second preimage attacks on these two hash functions are
still very expensive, the shattered paper demonstrates that hash
collisions are enough to re-purpose an OpenPGP signature.
https://shattered.io/
Please check my findings. A black box test would also be good, but I'm
not familiar enough with RPM to produce one.
Thanks,
Justus
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
