On Tue, Jan 18, 2000 at 02:18:52PM -0800, Jon Callas wrote:
You need to observe the changes in terminology if you refer to the new
PKCS #1.
Could you do me the favor of telling me what the changes in terminology
are? If I have to guess at what you'd like, I will probably disappoint you.
PKCS #1 v2.0 speaks of "encoding methods" rather than "padding", and
"block type 02" is now called EME-PKCS1-v1_5. EMSA-PKCS1-v1_5 means
making the DigestInfo and encoding it according to what was previously
called "block type 01".
The notes about backward compatibility don't mention that PGP 2
requires certain formats for some packet types.
I've just spent a half-hour on this. I know that PGP 2 compatibility
requires old length types, V3 data structures (keys and sigs), and only
RSA, MD5, and IDEA. Is this what you want me to say in a hint? Is there
something more subtle that I'm forgetting, but once you mention it I'll
say, "Duh, of course"?
For example key and signature packets must use length type 1, it
doesn't accept length type 0. I descibed that on this list quite some
time ago.
The security notes should mention that only v3 RSA signatures are bound to
the hash algorithm, so that v4/DSA signatures can be forged if any one of
the hash algorithms is broken, even if the signer doesn't use that algorithm.
I think I'm confused here. Suppose I have an implementation that does DSA
with SHA-1. Let us also suppose that Tiger gets broken. How does this
affect my DSA/SHA signature?
Then if I want to forge a signature, I find a message for which the
Tiger hash value is identical to your original SHA-1 hash. Unless
your original signature was a v3 RSA signature, nothing in OpenPGP
prevents me from setting the hash algorithm identifier for that
message to Tiger. That's why the RSA value in PKCS #1 contains a
DigestInfo, and why the DSS specifies SHA-1 as the only signature
algorithm. Putting the hash algorithm identifier in the data
protected by that very hash algorithm is pointless.
That clearly is a cryptographic weakness in the protocol, so it has to
be mentioned in the RFC. (By the way, OpenPGP allows MD2 as a hash
algorithm without a warning about its security, so this attack may
well be practical. But even if the verifying implementation only
accepts algorithms that are not known to be insecure, allowing the
attacker to chose a hash algorithm makes the protocol weaker not
stronger.)