[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phil Zimmermann's suggestion for large ciphers
> 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
> - 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).
> 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
> 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.
> 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.
> 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.