vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

Normalize term styling

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-10 00:21:22 +01:00
parent 2d3240a976
commit f96e7ae243
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 8 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

16
book/source/15-migration.md
View file

@ -83,23 +83,23 @@ don't.
It might be tempting to consider migrating existing key material to the v6 format. Such a step should be considered very carefully though.
Unfortunately, keys cannot simply be converted into the new format, as amongst others key-ids and fingerprints will change;
Unfortunately, keys cannot simply be converted into the new format, as amongst others Key IDs and fingerprints will change;
An OpenPGP v4 fingerprint is calculated as the SHA-1 checksum of the normalized public key packet, which results in a 40 digit fingerprint. The key-ID is the *last* 64 bits of the fingerprint.
An OpenPGP v4 fingerprint is calculated as the SHA-1 checksum of the normalized public key packet, which results in a 40 digit fingerprint. The Key ID is the *last* 64 bits of the fingerprint.
On the other hand, a v6 fingerprint is calculated as the SHA256 checksum of the normalized public key packet, so it has 64 characters. The key-ID are the *first* 64 bit of the fingerprint.
On the other hand, a v6 fingerprint is calculated as the SHA256 checksum of the normalized public key packet, so it has 64 characters. The Key ID are the *first* 64 bit of the fingerprint.
As a consequence, identifiers in OpenPGP artifacts, such as issuer subpackets in signatures, or recipient key-IDs in PKESK packets issued by a v4 key no longer match the identifiers of the converted key material.
As a consequence, identifiers in OpenPGP artifacts, such as issuer subpackets in signatures, or recipient Key IDs in PKESK packets issued by a v4 key no longer match the identifiers of the converted key material.
Further, since v6 keys can only issue v6 signatures, they also can only verify v6 signatures, as otherwise there would be a downgrade vector where v6 keys could be tricked into verifying specially crafted v4 signatures, should a v4 vulnerability arise at some point.
Another motivation for converting old key material might be the desire to stay able to decrypt messages encrypted for the old key.
This won't be possible out of the box, as the key-id in the respective PKESK packet no longer matches that of the converted key, so at the bare minimum, the users implementation needs to be able to map key-ids. This is not a feature prevalent in the ecosystem though.
This won't be possible out of the box, as the Key ID in the respective PKESK packet no longer matches that of the converted key, so at the bare minimum, the user's implementation needs to be able to map Key IDs. This is not a feature prevalent in the ecosystem though.
What could be a better solution than manual key-id mapping would be to replace the PKESK headers of the messages though. Since the session-key for each message can easily be obtained by decrypting the message using the old key, the session-key can simply be repackaged for either the converted v6 key, or a freshly generated v6 key.
What could be a better solution than manual Key ID mapping would be to replace the PKESK headers of the messages though. Since the session key for each message can easily be obtained by decrypting the message using the old key, the session key can simply be repackaged for either the converted v6 key, or a freshly generated v6 key.
In conclusion, converting v4 key material to v6 in order to verify old signatures is not a valid argument.
Being able to read old messages using a converted key is also not really viable, since it is equally as simple to just re-create the PKESK headers for a fresh v6 key.
In conclusion, converting v4 key material to v6 to verify old signatures is not a valid argument.
Being able to read old messages using a converted key is also not really viable, since it is equally simple to just re-create the PKESK headers for a fresh v6 key.
```{admonition} TODO
:class: warning