[Cryptography] RFC: block cipher randomization

[Tom Mitchell]

On Mon, Jun 27, 2016 at 3:18 PM, Ray Dillinger <bear at sonic.net> wrote:

>
>
> On 06/27/2016 01:41 PM, Vlad wrote:
> > Thank you guys for the feedback!
> > Special thanks to Ray!
> >
>
> Jerry had a fine point too;  Any "extra" data sent, if your
> correspondent can't check it, is an excellent way for malware to
> exfiltrate data.  And malware will exfiltrate stolen data in any way
> possible.
>
> Grrf.  Recently dealt with malware exfiltrating data in DNS queries
> of all things, where the botmaster was intercepting traffic
>

Good info.
The xflitration of stuff that cannot be validate is a show stopper.
It allows a big outbound side channel that cannot be audited.
The side channel is as large as the data channel and could xflitrate
the data as a copy XORed with a key/pad known to a turned insider and
an external snooper.

Pseudo random is troubling in the context that it is knowable if
the state can be guessed which today is likely because the seed
size limits the set of streams not the period length.

Swap out the pseudo random data and insert a second set of encrypted  data
multiplexed by a PRN and a previously shared seed+N   that swizzles
bytes in words or longer might allow multiple encrypted messages to move in
parallel.
with improved security.   Each message encrypted with its own key might
have value
on long haul links multiplexed by a long period PRN or addional keyed
stream.
The multiplex decode could be a large encrypted block of PRN  that must be
decrypted with a third key.
A multiplexed stream set could complicate analysis of N messages each
with their own encryption.  And not waste data bandwidth excessively.




-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160629/0afcdd82/attachment.html>