[Rpm-maint] Porting RPM to Sequoia PGP

[Panu Matilainen]

On 11/1/21 14:07, Justus Winter wrote:
> Neal Gompa <ngompa13 at gmail.com> writes:
> 
>> On Thu, Oct 28, 2021 at 11:17 AM Justus Winter <justus at sequoia-pgp.org> wrote:
>>>
>>> Panu Matilainen <pmatilai at 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 at 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 at 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
>