[Rpm-maint] [rpm-software-management/rpm] Add new signature headers for Post Quantum Signatures (Issue #3363)

[Simo Sorce]

**The problem**
With the standardization of the new Quantum Safe algorithms from NIST and the pressure from US and international agencies to adopt Quantum Safe asymmetric cryptography it is time to consider how this will be done in RPMs.

**Context**
In the past, new algorithms would take years, even decades before being adopted by standard bodies, however the timelines today are compressed because there is a somewhat reasonable threat that Quantum Computers capable of breaking classic cryptography will actually be available "soon".

This means there is no time to wait for all existing OSs to grow support for QR algorithms and then have a flag day and change signature algorithms.

Moreover some of the new algorithms are pretty young and there are still some doubts on their ability to withstand cryptanalysis, therefore either double-signature or hybrid encryption schemes are being considered as the logical next step.

For RPM this means we should have the ability to produce RPMs that carry both a classic signature with the current format for backwards compatibility, and a new signature using Quantum Safe algorithms. 

The Openpgp standard is evolving in IETF to make available PQ algorithms for both encryption (KEMs) and Signatures, however they are bundling these changes in a new packet level format that will require new implementations of the libraries to be able to use it. This means that even if they come up with a hybrid scheme RPM will not be able to use it and provide backwards compatibility to older Operating Systems.

**Describe the solution you'd like**
The RPM format should evolve to be able to carry additional signatures (more than one) so that we can approach a transition to PQ signature schemes without disrupting the ability to install or even just verify RPMs on current OSs using the current classic signature.

**Describe alternatives you've considered**
The alternative is to update the signature scheme to a hybrid signature, this would meet the requirement of signing with a PQ scheme but would be extremely disruptive as legacy systems would not be able to check signatures at all.

**Additional context**
One of the reasons why the timelines are compressed and require (IMO) to support multiple disjoint signatures is the CNSA 2.0 document: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
See the timeline part for adoption of Software/firmware signatures.

Other nations agencies are developing similar plans.

**Note on signatures timelines**
For those wondering why CNSA 2.0 has such a timeline for software signing when IETF is focusing mostly on Online encryption (to prevent "harvest now decrypt later"), my hypothesis is that the NSA, in this case, is more grounded in reality than (software/standards) developers :)

Although harvesting is definitely a big threat the NSA knows that hardware gets actually deployed and *will not* be changed easily until its lifetime is spent, for some devices this lifetime is measured in decades, while most consumer stuff last 3-5 years.
If your device receives software updates that are signed with classic algorithms only, the downfall of classic algorithms means anyone would be able to attack the systems by providing updates with forged signatures. This is especially problematic for firmware and OS updates as they underpin any data being managed by this hardware.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3363
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/3363 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20241007/5d6bccf1/attachment.html>