Hi,
First off, thank you for such a swift reaction to one of the most serious
cryptographic vulnerabilities discovered in recent times. Let me just comment on
your comments.
Daniel Kahn Gillmor wrote:
MDC
---
The modification detection packets (sections 5.13 and 5.14) explicitly
specify SHA-1, and basically acknowledge that this choice may need to be
made more flexible in the future.
We should be very careful here. By being more flexible on MDCs, one makes the
system less secure. After all, it is sufficient to forge ONE of the valid MDC
functions for the MDC-protected packet to check. There is a reason (with a good
discussion in the archives of this list, if I am not mistaken) why there is no
algorithm agility in OpenPGP MDC.
Also, MDC needs to be secure against second pre-images, not against collisions.
Collision-resistance is not a requirement for MDCs.
Fingerprints
------------
Fingerprints (section 12.2) are specified as an SHA-1 computation.
While this isn't an explicit reliance on SHA-1 for cryptographic
security (and the RFC makes it clear that there is a non-zero chance of
fingerprint collisions), the real-world use of fingerprints as unique
identifiers for keys poses a serious risk to OpenPGP infrastructure
should SHA-1 become further compromised.
There are many more problems with current OpenPGP key IDs and fingerprints. I
think that these are in need of a major overhaul. Here are two other problems
with fingerprints and keyIDs:
Creation date is hashed in the fingerprint, thereby allowing the same key with
different fingerprints of which 31 bits are of the attacker's choosing,
effectively shaving off 31 bits off the attacker's task (in other words, making
it 2 billion times easier on average).
Also, fingerprints and key IDs are hexadecimal, which makes them
super-inconvenient with mobile phones with numeric keypads.
Revocation keys
---------------
Section 5.2.3.15 defines a way that key A can allow key B to
authoritatively issue revocation signatures on A's behalf, including key
revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and
certification revocation (sigtype 0x30). However, this mechanism relies
on the fingerprint of B being unique. Since the fingerprint itself is
bound to SHA-1, this presents a risk to users of this feature of the
specification should SHA-1 become further compromised.
Again, collisions don't seem to be a problem here.
As the IETF working group for OpenPGP, we probably should start actively
working to resolve these issues so we can have infrastructure in place
well before SHA-1 is similarly compromised. Any suggestions? I'm new
to the WG, so i don't have any experience addressing concerns like this.
I'm particularly concerned about fingerprints, since they is used widely
in the real world (e.g. i have my fingerprint on my business card). I
can imagine relatively straightforward technical measures to resolve the
other concerns.
I think, fingerprints should be dealt with as part of the shift to v5 keys.
However, formulating reasonable requirements for fingerprints sounds like a good
way to kick off the design process of v5 key format specification. I will write
up a few ideas soon.
Regards,
--
Daniel
signature.asc
Description: OpenPGP digital signature