Re: Phil Zimmermann's suggestion for large ciphers

[uri <uri@xxxxxxxxxxxxxx>]

hal@xxxxxxxx says:
> 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.
> ...................... 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.

Good. About time.

> These concerns include -
> 
>  - The non-standard sync operation after the check bytes are handled

Kill it.

>  - The non-standard treatment of IV

Later.

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

Fix it.

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

I kinda like the idea of constant zero IV and plaintext prefixed with
128 random bits... Looks better than the "traditional" IV to me...

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

Make the "pseudo-IV" prefix partially non-random - i.e. the last two 
bytes being checksum for the other 14. No big deal security-wise and
noticeable help in detecting the right key.

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

Good enough.

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

Sure - but I still prefer "hidden" IV in the shape of plaintext prefix,
and "visible" IV all zeroized...

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

Exactly. And this is not a MAC - it's an MDC at best (Modification
Detection Code). I do not think MAC is warranted here.

In short - IMnotsoHM no need for keyed MAC or MDC. Plain SHA-1.

> Another issue is whether to use a fixed hash like SHA-1 rather than
> allowing the specification of a hash algorithm in the header. 

Shooting from the hip - no need for plenty of hashes. SHA-1 is 
good enough for this purpose.

> The threat model is very different from the
> case of cryptographic signatures, and a fixed hash like SHA-1 should
> be suitable.

It is.

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

Nah, IMNSHO isn't worth it.

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

So? Compared to cost of one RSA or DSA operation, one SHA-1 is negligible.
Who cares?

> The signature provides integrity protection as
> well as authentication, and so it is wasteful to also provide integrity
> protection as part of the encryption.

"Penny-wise, pound-foolish". I'd rather not do things in dozens of
different ways. Phil is correct here - it is better to have that
extra "wasteful" protection.
-- 
Regards,
Uri		uri@xxxxxxxxxxxxxx
-=-=-=-=-=-=-
<Disclaimer>