1. There are actually two forms of the SKESK. The first is when the key
is derived from the passphrase (old style) described by the paragraph "If
the encrypted session key is not present...". If this type is present, it
should be the only SKESK present (and no PKESK).
2. The S2K structure also contains a byte describing a symmetric
algorithm. For form in 1. above, it MUST be the same as what is used to
encrypt the message. This should also match the second octet in the
SKESK body.
3. For the other form, you can have multiple PKE packets and multiple
SKESK packets, apparently in any order. You need at least one, but there
is no strict upper limit.
4. For form 2, the S2K cipher type byte must be the algorithm used to
decrypt the session key for the message. When that is decrypted, the
first octet must match the 2nd octet of the SKESK body and the algorithm
used to encrypt the message.
5. For form 2, the only check is the match between the 2nd octet of the
SKESK body and the first of the decrypted session key. Multiple SKESKs
can produce multiple possible keys and each will have to be tried to see
if the 10 byte check will work (since there is no checksum).
6. Do I scan the PKESKs first, and if one works ignore the SKESKs, or do I
ask for a passphrase anytime I encounter a SKESK? If there was a rule of
the form "PKESKs MUST come before SKESKs" this would be easier.
7. Without padding or something similar just checksums aren't really that
good since N random bytes will tend to coalesce around 127.5*N. With
padding, the first zero byte must occur N+3 bytes before the end, the
following byte must be the valid ciphertype, and the checksum much match.
--- reply to tzeruch - at - ceddec - dot - com ---