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.
Does the spec say that V3 keys cannot use string-to-key specifiers,
and/or that it must use only the Simple S2K? I don't see that, but maybe
I am not looking in the right place. Neither 3.6.X nor 5.5.3 say that.
5.5.3 describes the difference in terms of what is encrypted, but doesn't
prevent you from using the new S2K packets. Is there someplace else
where it is mentioned?
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?).
It is true that you have to be able to read ASN.1 to understand this part
of PKCS-1. The actual code requirements are very simple, and perhaps we
should put them into the spec as you suggest. Our SHA-1 prefix looks like:
0x30, /* Universal, Constructed, Sequence */
0x21, /* Length 33 (bytes following) */
0x30, /* Universal, Constructed, Sequence */
0x09, /* Length 9 */
0x06, /* Universal, Primitive, object-identifier */
0x05, /* Length 8 */
43, /* 43 = ISO(1)*40 + 3 */
14,
3,
2,
26,
0x05, /* Universal, Primitive, NULL */
0x00, /* Length 0 */
0x04, /* Universal, Primitive, Octet string */
0x14 /* Length 20 */
/* 20 SHA.1 digest bytes go here */
You follow this by the 20 digest bytes, then pad it with block type
1 from PKCS-1 section 8.1. We could take out the comments and it would
be pretty concise:
0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 43, 14, 3, 2, 26, 0x05, 0x00, 0x04, 0x14
Similar structures could be provided for the other hashes. This might
be a better way to do it.
MD2 was just added and is 128 bits if I remember right. I didn't ask why,
but maybe it would be appropriate.
MD2 is used in some existing X.509/SSL signatures. Although it is only
128 bits there are no partial attacks against it as with MD4 and MD5.
12.7
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.
Yes, I wrote up that long description because I thought you were asking
how it worked, and Jon put it in the spec as an explicit example of
how the feedback works. I think the description in the earlier part
of the spec was OK but if we do want this kind of long description then
perhaps we should also do one (or two for the two cases) for the secret
key encryption as well.
Hal