ietf-openpgp
[Top] [All Lists]

Re: Conventional Encryption Keys, 5.3 - more notes

1998-03-26 18:25:13
tzeruch(_at_)ceddec(_dot_)com writes:
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).

Yes, this is true.

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.

No, it doesn't.  The S2K object has a hash algorithm but no encryption
algorithm specifier.  So there is no matching involved here.

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.

That sounds correct.

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.

There is no S2K cipher type byte.  See section 3.6.1.  So there is no
need to match here.

There are two "layers" of encryption being used in this case.  The
message is encrypted with a (random) SK, using a conventional encryption
algorithm.  Then the SK is concatenated with the algorithm ID, encrypted
with the hashed passphrase and stored at the end of the SKESK block.
That second layer of encryption can use a different encryption algorithm.

The algorithm for that second layer is in the SKESK block, 2nd octet.
The algorithm for the message encryption is then revealed when the SK
is decrypted.

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).

There is no match check.  You have to try the passphrase against each
SKESK, and then do a test decryption of the first 10 bytes of the message
to see if it works.  You are right that a checksum would help here,
although it causes me backwards compatibility problems if we change it.
(If we do change it, we should add an IV for the SK encryption layer.)

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. 

You have the same problem if there are multiple PKESKs and you have the
private key for more than one of them.  We scan them all.

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. 

Yes, when we redo this from scratch it would probably be better to do
something better than a simple checksum.

Hal

<Prev in Thread] Current Thread [Next in Thread>