<div dir="ltr"><div dir="ltr">On Tue, Feb 9, 2021 at 4:00 PM Viktor Dukhovni <<a href="mailto:cryptography@dukhovni.org">cryptography@dukhovni.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 09, 2021 at 03:40:21PM -0500, Phillip Hallam-Baker wrote:<br>
<br>
> If I do go with random, is there a cheap way to generate random padding I<br>
> should be thinking of? I don't need this to be particularly random.<br>
> <br>
> One possibility is to put the zeros through GCM with a different key. Seems<br>
> wasteful though.<br>
<br>
Perhaps something like Strobe:<br>
<br>
    <a href="https://strobe.sourceforge.io/papers/strobe-latest.pdf" rel="noreferrer" target="_blank">https://strobe.sourceforge.io/papers/strobe-latest.pdf</a><br>
<br>
might be a decent framework and may provide a natural way to do padding,<br>
by just sampling the key stream.<br>
<br>
As for padding with zeros or random, I'd go with zeros.  I'd be more<br>
concerned about subliminal channels in random data than known plaintext<br>
attacks on AES.<br></blockquote><div></div></div><div> <br>The use of zeros will frame the portion of data that is important. <br><br>A PRN generator or data from the hardware RNG if available might obscure what is and is not payload. </div><div><br>Benchmark a couple options including a block of zeros. <br><br>A limited block of RNs can be XORed with a cache line long RN and the <br>limited block refreshed cache line by cache line in a lazy async way so the initial</div><div>block bits are only used a small N times.   Tune N over time. <br><br>Some cache hardware will be fine without cache line concerns, benchmark.<br><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">          T o m    M i t c h e l l ( o n   N i f t y E g g )<br></div></div></div></div></div></div></div></div></div>