On Fri, 24 Aug 2001 09:07:01 -0400, Michael Young said:
Hal Finney offered the following alternative, which I like
much better than tweaking the S2K itself:
Another place we could represent the alternative format is the byte
which comes shortly before the S2K in the secret key packet. This
byte is fixed at a value of 255 to flag that an S2K is in use. We
could perhaps use some alternate value for this byte to flag that the
private key is using a different form of checksum protection.
Perhaps a value of 254?
I certainly support this. So what about this:
- One octet indicating string-to-key usage conventions. 0
| indicates that the secret key data is not encrypted. Values 1
| to 127 are symmetric-key encryption algorithm specifiers.
| Values 128 to 253 are reserved. A value of 254 indicates that
| that a string-to-key specifier is being given, 255 indicates
| the same but makes use of the deprecated two-octet checksum.
| - [Optional] If string-to-key usage octet was 254 or 255, a
one-octet symmetric encryption algorithm.
| - [Optional] If string-to-key usage octet was 254 or 255, a
string-to-key specifier. The length of the string-to-key
specifier is implied by its type, as described above.
| - [Optional] If secret data is encrypted, eight-octet Initial
Vector (IV).
- Encrypted multi-precision integers comprising the secret key
data. These algorithm-specific fields are as described below.
| - If the string-to-key usage octet was 254 a 20 byte SHA-1 digest
| of the algorithm-specific portion. Otherwise a two-octet
checksum of the plaintext of the algorithm-specific portion
(sum of all octets, mod 65536).
[....]
| The 20 byte SHA-1 digest that follows the algorithm-specific
| portion is computed by hashing the plaintext of all the
| algorithm-specific octets (including MPI prefix and data). It is
| always encrypted like the algorithm-specific data. The deprecated
16-bit checksum that follows the algorithm-specific portion is
the algebraic sum, mod 65536, of the plaintext of all the algorithm-
specific octets (including MPI prefix and data). With V3 keys, the
checksum is stored in the clear. With V4 keys, the checksum is
encrypted like the algorithm-specific data. This value is used to
| check that the passphrase was correct. Implementations SHOULD only
| use the 20 byte SHA-1 digest.
--
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus