Gary Howland <gary(_at_)hotlava(_dot_)com> writes:
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> wrote:
[lack of integrity check in PGP bulk symmetric encryption]
I think the example given is that someone might use this (symmetric
encryption) to send commands to a remote command executer which would
be trusted because it was encrypted with a shared passphrase. This
shows that the last command say could be garbled, resulting in a null
operation and potential security problem.
With known plaintext, the last 8 bytes can be set to anything the attacker
desires - so it's not just a case of removing or randomly corrupting data.
Indeed. Worse than that even -- you can modify arbitrary blocks, and
because of the way ciphertext error propagation works in 64 bit (ie in
cipher block size feedback) CFB mode only the following block will be
garbled, further blocks will recover.
The last block can be altered without any garbling at all because
there is no following block.
You can find the paper for the talk at:
http://www.hotlava.com/doc/index.html
Perhaps you covered the above, as I hadn't read your paper; will read.
Of course the attack is harder if one must cope with compression --
when we discussed this before you considered it possible to do even
with compression -- I tend to agree, though it will limit your
flexibility in that you will likely have to limit yourself to last
block attacks otherwise the following garbled block will likely
corrupt the compression, plus you will be limited to matching the
compression message bit length which is stored inside the encryption
envelope. (I am presuming compression is not necessarily a mulitple
of 8 bits long -- this assumption could be wrong, as I am not familiar
with ZIP algorithm, this assumption is based on huffman encoding).
Ciphertext error recovery properties have interesting implications for
protocol modifications to add message integrity protection -- for
instance appending a MD5 digest of the message to the plaintext prior
to encryption would not solve the problem.
I think a keyed MAC such as HMAC would do the trick with the MAC key
and the MAC output both being inside the encryption envelope.
You would want to check that MAC key and ouput position alignment and
padding in the modified protocol do not weaken the brute force
resistance to modification provided by the MAC key size.
Adam