[Cryptography] Low grade randomness for padding.
peter at tsto.co.uk
Wed Feb 10 18:49:13 EST 2021
On 09/02/2021 22:22, Jon Callas wrote:
>> Zeros: simple, minimizes opportunity for side channel games
>> Random: minimizes known plaintext for attacker.
>> If I do go with random, is there a cheap way to generate random padding I should be thinking of? I don't need this to be particularly random.
>> One possibility is to put the zeros through GCM with a different key. Seems wasteful though.
> I would do zeros. It minimizes all sorts of issues, starting with side channels, going through covert channels etc. (remember when people stressed out over DSA covert channels?) as well as other things like the inevitable subtle error of the random stuff being interpreted and not being able to actually test the bizarre behavior after the fact.
> If you wanted a quick way to do random numbers, run AES in counter mode or something like it, or iterate your favorite hash function.
> However, zeros are also a form of low grade randomness, too, and minimizes all sorts of issues, as stated above.
I haven't analysed the application, but in general cryptographically
speaking low-grade randomness means guessable.
If being guessed hurts then you need high-grade randomness - if it
doesn't then zeros will do.
There is another argument, in that adding something else slightly
difficult can make an attackers job harder - but unless you are going
from computationally feasible to unfeasible I don't think it has much merit.
One other source of attacker information might be if a packet contains
bit 7 plus one or two (or zero) bits of data plus a lot of identical
padding. An attacker might find a few identical packets and guess the
plaintext - this gives him a known ciphertext/plaintext pair. Some
randomness (or even a packet counter :) will deflect this.
Phillip Hallam-Baker wrote:
> Kent Borg wrote:
> Another concern is leaking data through message length. (Encrypted
> voice can frequently understood just on data sizes over time.)
> Padding with random data fights that
> And packet timing...
Don't forget constant packet rate. And if you are doing voice then do
not stop sending packets at constant rate when one party is not speaking
- users can be identified that way.
More information about the cryptography