On Thu, 23 Apr 1998, Hal Finney wrote:
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?
SHOULD not as opposed to MUST not? Capitalizing a Should does not make it
a Must, and the only way to generate a cipher alg other than IDEA is with
a new implemetation. Why say Cipher alg instead of IDEA when you mean
IDEA (to be backward compatible), unless you are trying to say if you want
to be slightly noncompliant it is fine to be noncompliant using 3DES
(which is unpatented and thus would make some sense).
By saying "Cipher Algorithm" instead of "IDEA" you imply that there is a
reason other than backward version interoperability to use this mode.
V3 keys can switch to using the new iterated/salted passphrase hashing,
which is a major security improvement.
The spec says V4 uses the new, V3 uses the old. Note that there are only
two differences between V3 and V4 secret key packets, and the other is the
version number at the head of the packet. It would be easy to modify
things to use V4 S2K protection on V3 keys, but the spec should say this
is permitted on a V3 key.
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.
Get a copy of the PKCS-1 spec and try writing something from it. Without
looking at the preformatted number I challenge you to determine the other
bytes in the packet. Even given SSLeay's ASN1 support it takes about 10
lines (optimizing more than is proper). Unless I haven't seen a good
version of the spec (is there one beyond that on RSA.com?).
If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits,
...
We really don't want to encourage any more use of MD5.
MD2 was just added and is 128 bits if I remember right. I didn't ask why,
but maybe it would be appropriate.
My preferred approach is simply to disallow non-SHA hashes with DSA.
That's what DSS says, after all.
Sounds like there is a missing SHOULD NOT
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.
But assuming I want to implement it, how should I do so? Or equally
reasonable would be to simply allow one signature per clearsigning.
"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.
PGP 2.6.2 probably won't like it, but instead of choking early on the
Hash, I am not sure what it would do beyond saying "invalid" signature.
Worse, and OpenPGP implementation reading a 2.6.2 message would
automatically do a useless SHA1 hash, then have to rewind and do MD5, as
would the existing implementations.
Also the whole point of having headers is to avoiding the rewind
operation. I could initiate both MD5 and SHA1 hashes on the clearsigned
text (so only RIPEMD160, HAVAL, and MD2 would need to be explicitly
specified).
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.
But implementors might also want to import secret V3 keys, so will need
the general algorithm. And I don't use any of the FR, FRE or other
registers described. I simply copy the last 8 bytes (actually the cipher
block size, but all are 8 so far) of cyphertext into the IV and set the
IVcount to zero.
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).
Forging signatures by forging the hash value is obvious. However imagine
something like a timestamping service which signs arbitrary text. I could
send things with known hash values to be signed, like 0, 1, 2, 4, ... I
would have to go back to the mathematics, but that is the origin of the
threat because I might be able to derive the secret key.
But if you want only SHA1 for DSA, and someone breaks SHA1 (without DSA)
this could be interesting.
--- reply to tzeruch - at - ceddec - dot - com ---