ietf-openpgp
[Top] [All Lists]

Re: Phil Zimmermann's suggestion - Implementation?

1999-04-13 10:13:20
On Mon, 12 Apr 1999 hal(_at_)rain(_dot_)org wrote:

I spoke with Phil Zimmermann on the phone about the issues raised by
moving to larger block ciphers, and he made the following proposal.

These concerns include -

 - The non-standard sync operation after the check bytes are handled

 - The non-standard treatment of IV

 - The lack of detection of message modification unless the message is
   signed (many people don't like to sign their messages for legal reasons,
   but they don't want them altered).

We would define a new encrypted packet format which would be similar to
the current one but which would resolve these problems.

Note that what you are defining is a different "method" or processing
layer.  This is NOT best implemented using different cipher numbers, but
with a range of cipher numbers or some other key indicating the new usage.

The current structure could be described as follows:

Plaintext -> IV/CFB xor -> Ciphertext
                ^
                |
   Secret -> Cipher

(By secret I mean all material, both key and initial IV if nonzero, etc.).

The IV/CFB xor box resets at 10.

The new model becomes (please correct ommissions)

Plaintext -> MAC append -> IV/CFB xor -> Ciphertext
                               ^
                               |
                   Secret -> Cipher

The IV/CFB box is different.  So why not just define a new IV/CFB mode or
method instead of jamming this definition into the cipher?

For now, I would prefer looking at a way of specifying the new IV/CFB or
whatever *method* as different from specifying the underlying cipher.

Also the MAC gives me some indigestion.  There are uses of this for stream
processing, and the MAC in this format needs an OOB EOF and processing. 

And to ask a question, how do I know where the MAC is?  I have to decrypt
and hold back 20 bytes just in case I see the EOF?  The new stream format
might have EOF detect problems there, i.e. I don't know where the MAC is
until I am past it.  (This is easily addressed, so should be before
proceeding).

(See my comments following)

With this approach, rather than patching the spec to deal with large
block ciphers in the existing packet format, we would say that the
existing packets should only be used for ciphers with 64 bit blocks.
Larger ciphers must use the new format.  Again, this is a perfect
opportunity to make this change because large ciphers won't be backwards
compatible, anyway.

Is there a particular reason not to use the old ciphers with the new
format (if it is available)?  Other than backwards compatibility - which
you won't have anyway?

We have also discussed providing integrity protection via some
modification to the signature packet format rather than by a new form
of encrypted packet.  There would be a special kind of "signature" which
would just consist of a hash of the message to protect its integrity.

Such as a signature with a "zero" encryption algorithm that would just
store the 20 bytes of the SHA-1 hash?  This could be easily added to the
existing code (with provisos that it doesn't display as a signature).

However, Phil argues that this kind of integrity protection is inherently
tied to the use of encryption.  It has no functional effect if not used
in conjunction with encryption.  This is unlike our other signatures,
which are cryptographically useful transformations even on their own.
Because of this close tie to the encryption functionality it makes most
sense to make it part of the encrypted packet.

Or simply encrypt the signature with the symmetric algorithm the message
was encrypted with (instead of the PK signature algorithms).  This leaves
all the existing hashing code where it is and only requires a mod to the
final stage (and perhaps preservation of the cipher state on EOF).

Doing a MAC within the encryption packet now adds a layer on the inside,
which will be there even for signed messages.

I really don't like extra layers if an existing layer can provide the
functionality.

However, Phil points out that it is often the case that a signature
cannot be verified because the signing key is not available.  In that case
there is no integrity protection at all.  Putting integrity protection in
the encryption layer ensures that all encrypted messages have integrity
protection.

Since you can have multiple signature packets, adding the symmetric MAC
"non-signature" adds this function without the layer.

Summing up, we have an opportunity now to move to a new encrypted packet
format at the same time as we begin supporting new ciphers.  We can
fix some of the problems which people have been complaining about for
years, without facing backwards compatibility issues.

Please fix the symmetrical encryption packet lack-of-checksum while you
are at it.  (This is when you have a pass phrase protecting more key
material - the second has no checksum so you can't tell if the key is good
without decrypting some of the ciphertext).