Gianpiero Carpinelli, a developer at Canonical, has submitted a merge request to add SHA3-256 and SHA3-512 support to APT (Advanced Package Tool), the package manager used by Debian and Ubuntu. The goal is to give long-lived Ubuntu machines the option of moving to a different hash function in the future.
The proposal was submitted on September 29 and updated on October 2. As of October 4, it had not been merged. If clients can already verify SHA-3, then when distributors someday need to change hash algorithms, existing machines are less likely to stand in the way of the transition. To understand this change, it helps to separate two things: clients becoming able to handle SHA-3, and Debian and Ubuntu distribution servers actually switching to it.
Handling SHA-3 is not the same as adopting it
The proposal adds the ability to read and verify SHA3-256 and SHA3-512 to APT's libapt-pkg library. It covers Release, Packages and Sources, the indexes used for package distribution.
It also adds the ability to output SHA3-256 and SHA3-512 hashes to apt-ftparchive, the tool that generates distribution indexes. However, SHA-3 generation is disabled by default. It is designed to be enabled explicitly with --sha3-256 or --sha3-512, or with the corresponding configuration options.
In this proposal, client-side verification, generation of distribution metadata, actual adoption on distribution servers, and OpenPGP signatures are each treated as separate matters.
Organizing the proposal as updated by Carpinelli on October 2, along with his September 29 explanation to developers, by role gives the following picture:
| Component | What the proposal adds | Conditions for use / out of scope |
|---|---|---|
| APT on the client | Ability to read and verify SHA3-256 and SHA3-512 in indexes | Used once a SHA-3-capable APT is installed and the distributor lists SHA-3 hashes |
apt-ftparchive |
Ability to output SHA-3 hashes into indexes | Enabled by administrators through options or configuration; not output by default |
| Package distribution servers | Generation capability needed to list SHA-3 | Which algorithms to list is up to the distributor. This does not decide adoption on official servers |
| OpenPGP signatures | Not covered by this change | Changing the digest algorithm used for signatures is outside the scope of this proposal |
This table separates the features included in the merge request from the operational decisions still to be made. It is not a list of features APT already provides.
The September 29 email also discussed whether to enable SHA-3 generation by default, but the proposal as updated on October 2 generates it only when explicitly requested. It is important not to confuse an idea floated during discussion with the implementation now under review.
On the client side, when a distribution server lists multiple hashes, APT prefers the newer SHA-3 ones. The priority order defined in the current code is SHA3-512, SHA3-256, SHA512, SHA256.
SHA-3 support is also added to by-hash, which fetches indexes using a file's hash as part of the URL. If a SHA-3 by-hash path is available, it is used, with a fallback to the regular file path when necessary. The change makes both how an index is fetched and which hash is used to verify its contents SHA-3-aware.
According to the developer's explanation, during downloads a client computes only the hashes that the distributor actually lists. In other words, merely adding SHA-3 code to client-side APT will not increase SHA-3 computation as long as current distribution servers do not use SHA-3.
That said, this is not the result of measuring the processing load of listing SHA-3 alongside existing hashes, or the effect on APT's overall performance.
APT verifies from the signed index down to the package
Official Ubuntu packages are not judged trustworthy by checking each .deb file in isolation. Canonical's security documentation explains a mechanism that links a signed index to the actual package.
First, APT verifies InRelease, which carries an OpenPGP signature. It records hashes used to confirm the correct Packages index files for each architecture and distribution component.
Next, APT checks whether the hash of the fetched Packages file matches the value recorded in InRelease. Packages in turn lists the name and hash of each .deb file, so the contents of a downloaded package can be checked against it. For source code distribution, the same verification is performed through Sources.
If only an intermediate file is tampered with, it will no longer match the hash recorded one level above. If an attacker also changes the hashes within the index, the higher-level file that references that index would have to be changed too, and the chain ultimately leads back to OpenPGP signature verification.
Adding SHA-3 increases the hash functions available for checking file contents in this chain of verification. It is a separate task from changing the digest algorithm used in the OpenPGP signature itself.
The property that matters here also cannot be summed up simply as being "cryptographically strong." Canonical explains that this verification method depends on a hash function's second-preimage resistance.
Second-preimage resistance is the property that, given a file, it is hard to find a different file with the same hash. It differs from collision resistance, which concerns finding any two different pieces of data with the same hash, in the conditions given to the attacker. NIST's definitions also distinguish the two.
Successful cryptographic verification by APT is also not the same as the distributed software being safe.
For example, a package signed by a third-party repository with its own key can be verified by APT if the user configures that key as trusted. Canonical likewise says that, for third-party repositories, users must judge for themselves whether the operator can be trusted. Adding more hash functions does not automatically earn trust in the repository itself.
Implementing a differently designed hash ahead of long-term support
When a Debian developer asked about the purpose, Carpinelli explained that it is to ensure "diversity" among hash functions.
The reasoning is that during the long support period for Ubuntu 24.04, if a situation arose in which SHA-2 could no longer be used safely, the distributor could not simply switch to a new algorithm unless already-deployed machines could understand a hash from a different family.
This does not predict that SHA-2 will be broken soon. The idea is to ship the supporting capability in advance, because if a hash function must be replaced in the future, existing machines' lack of support for the new algorithm would itself be an obstacle to migration.
Even if a distributor changes only the servers to a new algorithm, older machines that cannot understand those hashes cannot verify packages. So normal software updates are used to deliver support for the new algorithm to clients ahead of time.
This offers an option to migrate immediately when needed, rather than starting only after a problem emerges by implementing the new algorithm and distributing it to every long-running machine.
SHA-3 is not simply a longer-output version of SHA-2. It is a family of hash functions standardized by NIST based on Keccak, with a design different from SHA-2. For example, SHA-256 and SHA3-256 both output 256-bit hashes, but their internal mechanisms differ.
Being able to choose differently designed hash functions for the same purpose is what Carpinelli means by "diversity." NIST's standards still include both SHA-2 and SHA-3, so it is premature to read this proposal as the start of a migration from SHA-2 to SHA-3.
Conditions around the Ubuntu LTS support period also need to be distinguished. According to Ubuntu's official support table, standard security maintenance for Ubuntu 24.04 LTS runs until May 2029, and Expanded Security Maintenance through Ubuntu Pro runs until May 2034. With the Legacy add-on, security maintenance and support can be extended to May 2039.
The "10 to 12 years" cited as a development motivation in the proposal should therefore not be taken as the support period common to all Ubuntu 24.04 users.
The longer an environment is supported, the longer it keeps using the same cryptographic algorithms. What is being prepared here is an option for the case where the hash algorithm must be changed during that period. Because the digest used for OpenPGP signatures is out of scope, this change alone also does not complete a migration of all the cryptography APT uses.
Listing SHA-2 and SHA-3 together enables a gradual migration
The fact that older APT versions can ignore an unknown SHA-3 field helps with a phased migration.
If a distributor lists both SHA-2 and SHA-3, newer APT with this change prefers SHA-3, while older APT that does not understand SHA-3 can keep using the existing SHA-2.
The later stage of removing SHA-2 and listing only SHA-3 is a separate matter, though. Being able to ignore a new field does not mean older APT can verify a repository made up of SHA-3 alone.
That leaves room for a staged approach:
- First, spread SHA-3 support to clients
- Have distributors list SHA-2 and SHA-3 together
- Once enough clients support it, remove the old algorithm if necessary
On the other hand, adding more hash algorithms means more values in the index files. In a September 29 discussion, dpkg developer Guillem Jover pointed out that adding 512-bit algorithms in particular increases metadata size.
Carpinelli has suggested that even if Debian or Ubuntu were to add SHA-3, they might in practice adopt only SHA3-256. This is one developer's outlook, however, and does not determine which algorithms official Debian or Ubuntu distribution servers will adopt.
Challenges remain on the package-generation side as well. According to Jover, if dpkg itself were to support SHA-3, the question would be how to handle the dependency on Digest::SHA3, which is not part of Perl's standard distribution.
The APT proposal, meanwhile, lets apt-ftparchive compute SHA-3 and fill in values even when the required hash is missing from a source package's .dsc information file. The design does not assume that every tool involved in distribution supports SHA-3 at the same time; instead, it fills in missing values at the stage where the index is generated.
This is preparation for a future switch, not a migration to SHA-3
There are also some smaller implementation changes.
The proposal makes OpenSSL 1.1.1 or later a build requirement and extends the cache format used by apt-ftparchive to support SHA-3.
A cache written by the new version of apt-ftparchive cannot be read by older versions and results in a "Cache record size mismatch" error. Anyone reverting from the new version to an older one must therefore delete the cache. This is because space for storing SHA-3 hashes is added to the cache.
In testing repositories that list only SHA-3, two pre-existing bugs in apt-ftparchive checksum generation were also found, and fixes for them are included in this merge request.
One is that, with MD5 disabled, checksums are not generated in Sources if the .dsc file lacks a required checksum. The other is that a hash algorithm cached once keeps being output even if it is later disabled.
Neither bug was caused by SHA-3 itself; testing a SHA-3-only configuration simply exposed existing problems.
What can be confirmed at this point is limited to the merge request adding SHA3-256 and SHA3-512 support to APT itself, and its design.
Which APT version will include it, whether it will be backported to Ubuntu 24.04 LTS, and whether official Debian or Ubuntu distribution servers will actually list SHA-3 are all decisions for the future.
This change does not mean SHA-2 will stop being used right away. What matters is delivering support to existing machines in advance, rather than starting to support a new algorithm only once it is needed.
If preparation on the long-lived client side is completed first, then when the hash algorithm someday needs to change, migration becomes more likely to proceed without waiting for old machines to catch up.