<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 27, 2016 at 3:18 PM, Ray Dillinger <span dir="ltr"><<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 06/27/2016 01:41 PM, Vlad wrote:<br>
> Thank you guys for the feedback!<br>
> Special thanks to Ray!<br>
><br>
<br>
Jerry had a fine point too;  Any "extra" data sent, if your<br>
correspondent can't check it, is an excellent way for malware to<br>
exfiltrate data.  And malware will exfiltrate stolen data in any way<br>
possible.<br>
<br>
Grrf.  Recently dealt with malware exfiltrating data in DNS queries<br>
of all things, where the botmaster was intercepting traffic <br></blockquote><div></div></div><div class="gmail_extra"><br></div>Good info.<br>The xflitration of stuff that cannot be validate is a show stopper.<br>It allows a big outbound side channel that cannot be audited.<br>The side channel is as large as the data channel and could xflitrate</div><div class="gmail_extra">the data as a copy XORed with a key/pad known to a turned insider and</div><div class="gmail_extra">an external snooper.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Pseudo random is troubling in the context that it is knowable if</div><div class="gmail_extra">the state can be guessed which today is likely because the seed</div><div class="gmail_extra">size limits the set of streams not the period length. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Swap out the pseudo random data and insert a second set of encrypted  data</div><div class="gmail_extra">multiplexed by a PRN and a previously shared seed+N   that swizzles </div><div class="gmail_extra">bytes in words or longer might allow multiple encrypted messages to move in parallel.</div><div class="gmail_extra">with improved security.   Each message encrypted with its own key might have value </div><div class="gmail_extra">on long haul links multiplexed by a long period PRN or addional keyed stream.   </div><div class="gmail_extra">The multiplex decode could be a large encrypted block of PRN  that must be</div><div class="gmail_extra">decrypted with a third key.  <br>A multiplexed stream set could complicate analysis of N messages each </div><div class="gmail_extra">with their own encryption.  And not waste data bandwidth excessively.<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>