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. 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. 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. 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. 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. 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. - 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). 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
/* gcc -o fipstest fipstest.c `libgcrypt-config --cflags --libs` `pkg-config --cflags --libs openssl` */
#include <stdio.h>
#include <gcrypt.h>
#include <openssl/evp.h>
int main(int argv, char **argc) {
int good = 1;
int enable_fips_mode = argv > 1;
if (enable_fips_mode) {
if (gcry_control(GCRYCTL_FORCE_FIPS_MODE)) {
fprintf(stderr, "WARN: Failed to get gcrypt into fips mode\n");
}
if (FIPS_mode() == 0) {
fprintf(stderr, "WARN: The current version of OpenSSL is not FIPS-capable.\n");
}
if (FIPS_mode_set(1 /*on*/) == 0) {
fprintf(stderr, "WARN: Failed to get openssl into FIPS mode\n");
}
}
gcry_check_version(NULL);
gcry_control(GCRYCTL_INITIALIZATION_FINISHED, 0);
gcry_md_hd_t h;
if (gcry_md_open(&h, GCRY_MD_MD5, 0) == 0) {
fprintf(stderr, "gcrypt allows MD5\n");
good = 0;
gcry_md_close(h);
}
if (gcry_md_open(&h, GCRY_MD_SHA1, 0) == 0) {
fprintf(stderr, "gcrypt allows SHA1\n");
good = 0;
gcry_md_close(h);
}
EVP_MD_CTX *ctx = EVP_MD_CTX_new();
const EVP_MD *md = EVP_md5();
if (md) {
fprintf(stderr, "openssl has MD5\n");
good = 0;
}
if (EVP_DigestInit_ex(ctx, md, NULL) == 1) {
fprintf(stderr, "openssl allows MD5\n");
good = 0;
}
md = EVP_sha1();
if (md) {
fprintf(stderr, "openssl has SHA1\n");
good = 0;
}
if (EVP_DigestInit_ex(ctx, md, NULL) == 1) {
fprintf(stderr, "openssl allows SHA1\n");
good = 0;
}
EVP_MD_CTX_free(ctx);
return good ? 0 : 1;
}
signature.asc
Description: PGP signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
