Re: draft agenda for San Jose meeting

At 4:26 PM -0800 12/2/96, Tom Weinstein wrote:
>If we are actually going to consider protocol changes at this time, or
>for the future, I'd also suggest a generalization of the block padding
>format.  I'd specify that blocks be padded with random data, and that
>that all blocks have (possibly zero-length) padding.  I'd also relax
>restriction on maximum padding length.  This would make it harder to
>perform a traffic analysis attack, but still allow implementations to
>forgo the padding if so desired.

I think this is a good suggestion, except that I would specify the contents
of the block data rather than using random data. I don't believe that
random data adds significantly to the security of the protocol, as any
significant communication will be well beyond the unicity distance; thus,
the verifiable plaintext of the padding won't aid attackers. The benefit of
using predictable data is that the peer can verify that padding is being
done as expected, which allows a greater rigidity around implementations,
which I believe aids security analysis.

If you'd like to avoid the padding data being known plaintext, you could
specify it in some what that it is unknown, yet verifiable. However, the
protocol should be strong against known-plaintext attacks anyway, as such
attacks are commonly available to attackers.

 - Tim

Tim Dierks - timd@consensus.com - www.consensus.com
     Software Haruspex - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Received on Tuesday, 3 December 1996 04:03:36 UTC