[Cryptography] RFC: block cipher randomization

[Ray Dillinger]

On 06/29/2016 05:02 PM, Tom Mitchell wrote:
> On Mon, Jun 27, 2016 at 3:18 PM, Ray Dillinger <bear at sonic.net> wrote:

> 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.

Except in this case, as described, it's not XOR'd - it's interleaved
with the "real" data, and then the mixture encrypted using an
ephemeral secret key shared with the legitimate correspondent.

The only creature in creation that's able to exfiltrate stolen data
over *that* channel, is the legitimate correspondent.  So while
uncheckable data in general provides an exfiltration channel, that
channel in this case is extraordinarily narrow.

> 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.

It's certainly no more troubling than the use of any PRNG as a stream
cipher, and that's a very common construction.

One could substitute PRNG output for the "random" numbers in this case,
with the N-bit initial PRNG state sent as the final N bits of the
interleaved data.  The problem, of course, is that the "fix" comes at
the expense of yet more CPU cost, and this construction is already too
expensive in CPU for any non-niche use.

> 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.

That's interesting as a simple-ish primitive for multiplexing and
demultiplexing garlic-routed messages. Admixture of many encrypted
channels in a single stream, where in order to separate and decrypt the
stream you need the stream key, but in order to read any part of a
channel you'd also need the channel key.  The cutover points between
different data channels would be determined by PRNG generated from the
shared stream key.  The endpoints, knowing the stream key because they'd
established the stream in the first place, could separate the
encrypted channels, remix them in different combinations, and
redistribute them using different streams.

Of course it's recursive; any "channel" in a given stream might contain
a stream of its own.

That mutation of the original idea might be a very good one; it could
enable continuous-streaming garlic-routed channels, with cutin/
cutout of particular channels on a realtime basis becoming stupidly
simple.  And it doesn't waste CPU/bandwidth on encrypting bits we don't
actually care about; it's just a simple way to multiplex/demultiplex
channels over a shared encrypted stream and doesn't spend (much)
more CPU/bandwidth than stream encryption normally would.


				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160629/31bf4eb6/attachment.sig>