RE: A hole in esp-stream-01

[Andrew Robison <[e-mail]>]

>From: 	Germano Caronni[SMTP:[e-mail]]
>Sent: 	October 29, 1996 5:24 PM
>
>[e-mail] wrote:
>> Now, remember, we turned the high bit off in the ciphertext byte,
>> and on in the plaintext byte.  What this means is that we subtracted
>> 128 from the ciphertext byte, and added it back in the plaintext
>> byte.  Thus, (C[4]* + P[4]*) = (C[4] + P[4]).
>> 
>> If we have to also deal with the CRC of this, so long as the CRC
>> polynomial is known, we can just flip the bits that would have
>> changed in the CRC, right?
>
>Right. Consider my proposals to 'fix' esp-stream as retracted. It either has
to be a real (fast) MAC, or a note in the 'Security Considerations'.
>What do you people prefer?

What about putting a random sized pad at the start and end of the packet
as follows such that a known plaintext attack would find it difficult to
actually correctly find the plaintext to change:

pad_length|pad1|original_packet|pad2|original_packet_length

If you assume that original_packet and original_packet_length are
completely or partially known, would it be possible to guess pad_length
and therefore bypass pad1 and pad2? If pad_length is a four bits
(padded out randomly to a byte) and pad1 and pad2 are randomly set
between 0 and 15 bytes, would this make it harder to make a successful
modification? With a basic 32 bit checksum of bytes it would be as
follows:

pad_length|pad1|original_packet|checksum|pad2|original_packet_length