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