[Cryptography] Key meshing (Re: [Crypto-practicum] Retire all 64-bit block ciphers.)

[Stanislav V. Smyshlyaev]

Dear Phillip,

Thank you for your question! Indeed, the key schedule question is really
important here – but I'd add a little about another issue. The thing is
that such a mode of operation relies on block transformation properties
(something close to APN properties of Boolean mappings) that could have
been not examined for a particular cipher when it was created.

And such a question should be examined separately for each cipher –
related-key attacks could be a problem for a large class of ciphers for
such a simple mechanism of changing a key. Moreover, it won't help neither
for resistance to side-channel attacks (the leakage info accumulated by
adversary after several blocks with "K, K+1, K+2..." can be used together
since the keys are quite close) nor to classical cryptanalysis methods (for
example, if you have some variant of linear cryptanalysis applicable, it
won't be too difficult to modify it from the case of finding relations on
"K" to the case of finding relations on {"K+i"}, where i is the number of a
section).

So if you change the key online, then you should better change it in some
"pseudorandom" way.

Kindest regards,
Stanislav


2016-08-31 1:33 GMT+03:00 Ray Dillinger <bear at sonic.net>:

>
>
> On 08/30/2016 09:22 AM, Phillip Hallam-Baker wrote:
>
> > Of course with DES you have the problem of weak keys but these days we
> > consider weak keys as disqualifying a cipher completely.
> >
> > The main reason for not doing this seems to be that the key schedule has
> to
> > be recalculated and that was expensive for DES. But that shouldn't be a
> > major problem on a modern CPU.
>
>
> Depends on how much and how often.  Servers in big server clusters
> are pretty precisely tuned in terms of how many connections they serve;
> what doesn't impose a detectable penalty on a desktop machine, still
> matters in terms how many servers you need to handle ten thousand
> simultaneous sessions.
>
> In response to your question, almost every Feistel-type cipher has
> poor key agility.  The construction you mention, if deployed and
> used for general purposes as a symmetric cipher, would multiply
> the cost of servers by a non-trivial amount.
>
> For a few brief years, the advance of CPUs was vastly in advance
> of the available bandwidth. The desktop machine that pegged its
> CPU for a few seconds of each day was the design target, and CPU
> costs didn't really matter.  But now it matters again because
> bandwidth allows people running servers to use all the CPU they
> can afford.
>
> For a few brief years, the advance of CPUs didn't permit them to
> be battery-powered under normal circumstances. The desktop machine
> with a plug in a wall socket was the design target, and CPU costs
> didn't really matter.  But now it matters again because CPUs have
> gotten small enough to run on batteries, but battery power still
> limits CPU cycles.
>
>                                 Bear
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160831/1f2bac6c/attachment.html>