I spoke with Phil Zimmermann on the phone about the issues raised by
moving to larger block ciphers, and he made the following proposal.
Phil suggests that we take advantage of the fact that when we go to large
block ciphers like Twofish, there are no backwards-compatibility issues.
We know that we need to make some adjustments to the spec with regard to
the large block size. Rather than trying to tweak the current symmetric
encrypted data packet spec, let us define a new encrypted data packet
which would be used for large ciphers and would solve some of the concerns
people have had with our existing encrypted data packets.
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.
The first thing in the packet would be the IV, of a size equal to the
block size of the cipher. It would be followed by the ciphertext, which
would be handled in CFB-n mode, where n is the block size of the cipher.
There would be no special shift or sync operations.
The plaintext would be prepended with a header consisting of check bytes
so that the proper key can be detected. The check bytes could be two
random bytes, followed by the same two bytes, repeated.
The plaintext would be followed by a SHA-1 hash of the plaintext data.
This would be checked after decryption and detect message modification
attacks.
This gives us a standard CFB mode, with a standard IV; a simple form of
redundancy at the beginning to verify the correct key; and a SHA-1 hash
at the end to protect the integrity of the data.
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.
We have talked about variants on this idea in the past. Let me briefly
try to address some of the issues which have come up.
One question is whether to use a keyed MAC, like an HMAC, for integrity
protection. A MAC is a Message Authentication Code, and is useful when
the two sides have authenticated themselves to each other. They have
some shared secret and they use that to authenticate the data as having
originated with the other. What we want is simple integrity protection.
For this purpose there is no need for a shared secret and it is
appropriate simply to use a hash to provide the protection.
Another issue is whether to use a fixed hash like SHA-1 rather than
allowing the specification of a hash algorithm in the header. There is
no need for variable hash algorithms in this context. The attacker does
not have access to the plaintext of the message. The SHA-1 hash is being
used essentially as a complicated checksum. There are certain limited
changes which an attacker can make to an encrypted message, and all we
need is that the hash function has a complex enough structure that the
attacker would not be able to alter the message and checksum to allow
it to continue to verify. The threat model is very different from the
case of cryptographic signatures, and a fixed hash like SHA-1 should
be suitable.
Allowing the specification of a hash algorithm would actually allow
some new attacks, as an attacker could potentially modify the message
to change the hash algorithm specification, at the cost of damaging
some other parts of the message. The recipient would then find that
the message had apparently been integrity-protected with an unknown
hash algorithm, and the integrity protection would be lost.
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.
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.
One objection to this linkage is that if the message is both signed and
encrypted, there is redundancy, since we compute an integrity protection
hash in the encryption layer, and also a signature verification hash
in the signature layer. The signature provides integrity protection as
well as authentication, and so it is wasteful to also provide integrity
protection as part of the encryption.
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.
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.
Hal Finney
NAI, Inc.