3.6.2.1, Cipher alg: use Simple S2K
... SHOULD NOT be generated. The only value for Cipher Alg should be 1 to
(IDEA) to maintain compatability, so why not just say 1 instead of saying
that you can theoretically use 3DES or CAST to do something you shouldn't
be doing?
A bit farther down, it says "it should be understood, but not generated."
Perhaps it needs some capital letters?
(this also creates problems if you don't allow promoting V3 secret keys to
V4 retaining the key id and other associations since you can't use the new
secret key encryption algorithm).
It is true that V3 keys have the secret key material encrypted slightly
differently, with the bit lengths in the clear. However most of what
is exposed is known values anyway. The size of n and e is known, the
sizes of p, q, u and d can be guessed to within a few bits. So there is
not much harm in exposing them. PRZ originally designed it like this to
have less known plaintext which would give a cryptanalyst a possible
opening.
V3 keys can switch to using the new iterated/salted passphrase hashing,
which is a major security improvement.
4.2.2.3 Five octet lengths
Nowhere does it say this SHOULD NOT be used after partial body lengths.
So can it occur in place of the One or Two octet lengths? If the idea was
to mimmic the old style CTB, I would think not.
4.2.2.4 describes the partial body length header, and says, "Another
length header (of one of the three types) follows that portion."
The "three types" should probably be enumerated as "one-octet, two-octet,
or partial", or else we should say "four types". As TZ says, the former
seems preferable, with the five octet length used only at the start of
the packet.
5.2.2
The full prefix isn't given, just the OID in ASN1 form. The fuller
version is sequence(sequence(object,null),octet-stream).
We are relying on PKCS-1 to explain how the byte stream is set up.
PKCS-1 does not specify the OIDs for the algorithms we are using, so we
provide those here.
If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits,
I would suggest the data be padded with zeros on the left, or repeat the
hash result. What about a hash with >160? I would suggest the rightmost
(least significant) 160 bits.
A reason to do this might be to use one hash algorithm for both V3 and V4
signatures, which would mean MD5.
We really don't want to encourage any more use of MD5.
I also think we should stick to SHA-1 with DSA signatures. If a different
hash is used, the client MUST expose the hash to the user so he can know
whether a strong one was used. Otherwise, if one of our supported hashes
were eventually be broken, someone could forge a DSA signature using the
weak hash, and the user would think the signature is OK.
My preferred approach is simply to disallow non-SHA hashes with DSA.
That's what DSS says, after all.
7. Cleartest signature framework
"The ASCII armored signature(s)" - for multiple signatures, is each
signature individually armored, or are the signature packets concatenated
and the whole armored?
Despite allowing multiple Hash headers at the top of a clearsigned
message, there is no support at present for multiple signatures in
clearsigned text in our PGP code.
"If there are no such [Hash:] headers, SHA-1 is used. So V3 Clearsigned
messages won't interoperate with V4 implementations? Or should the
default be MD5?
What PGP does is if there are no hash headers it saves up the message
and then when it reads the signature at the bottom it goes back and
hashes it. However for backwards compatibility perhaps assuming MD5
would make sense for OpenPGP.
12.7
This describes ONLY the cfb reset for the symmetrical packet. V3 RSA
secret keys also need the cfb reset (between MPIs), and they aren't
usually on a 10 byte boundary.
Perhaps this should be identified as the CFB mode used in symmetrically
encrypted data packets.
13
How can a broken hash algorithm leak a DSA secret key? (I would like a
reference noting the above interoperability problems, or would this only
affect a signing service where I could provide known plaintext).
I don't know if this is possible. However a weak hash could allow you
to forge signatures, as described in Handbook of Applied Cryptography,
section 11.66(iii).
Hal