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
Attachment:
signature.asc
Description: OpenPGP digital signature