Prev: Generic Crypto APIs ?
Next: in ElGamal, could you hardcode the generator for a public key and not lose security?
From: Mok-Kong Shen on 2 Mar 2010 10:46

As I understand it, one main feature of the stream cipher RC4 is its
array S, which contains a randomly ordered alphabet [0..255] that is
dynamically modified via swapping of two of its elements each time a
symbol is being processed. Wouldn't dynamics also be advantageous for
block ciphers?

One could perhaps say that certain dynamics is actually already
exploited in block encryptions. In the CBC mode, the processing
of a block is 'dynamically' influenced by the ciphertext of the
preceding block. However, what I mean here is dynamics within the
processing of the block algorithm itself (from its input to its output,
thus excluding the chaining value). Of course, very "wild" dynamics
could be very dangerous, for their effects couldn't be easily studied.
But couldn't some more or less "mild" dynamics nonetheless be allowed?
Consider, for instance, AES, where each round (excepting the last)
consists of the four components SubBytes, ShiftRows, MixColumns and
AddRoungkey in this order. Would it really matter very much, if the
order of these components is changed? As layman I guess it wouldn't.
If that's indeed true, then one could at algorithm initialization time
use the key to determine randomly an order for each round and
subsequently at run time dynamically modify these orders, employing
e.g. certain values taken during the processing of the preceding
block to do the modifications. In the same vein, the order of the round
keys could be dynamically permuted at run time. That such dynamics
would render analysis much harder seems evident, since it depends
ultimately on the particular plaintext being processed and hence is
unknown to the analyst. Note that all modifications mentioned above are
"mild", for we don't change e.g. the values of the round keys as such
but merely their order.

Thanks.

M. K. Shen
From: unruh on 2 Mar 2010 12:36
On 2010-03-02, Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote:
>
> As I understand it, one main feature of the stream cipher RC4 is its
> array S, which contains a randomly ordered alphabet [0..255] that is
> dynamically modified via swapping of two of its elements each time a
> symbol is being processed. Wouldn't dynamics also be advantageous for
> block ciphers?

That is in a sense what the various chaining modes try to give. But the
problem is recovery from errors. If one byte of the encrypted text
occurs, can the cypher recover from that and still decrypt the rest.
If the algorithm itself is dynamic, this would seem to be impossible.
The decryption of the current byte depends on all of the previous bytes.
>
> One could perhaps say that certain dynamics is actually already
> exploited in block encryptions. In the CBC mode, the processing
> of a block is 'dynamically' influenced by the ciphertext of the
> preceding block. However, what I mean here is dynamics within the
> processing of the block algorithm itself (from its input to its output,
> thus excluding the chaining value). Of course, very "wild" dynamics
> could be very dangerous, for their effects couldn't be easily studied.
> But couldn't some more or less "mild" dynamics nonetheless be allowed?
> Consider, for instance, AES, where each round (excepting the last)
> consists of the four components SubBytes, ShiftRows, MixColumns and
> AddRoungkey in this order. Would it really matter very much, if the
> order of these components is changed? As layman I guess it wouldn't.
> If that's indeed true, then one could at algorithm initialization time
> use the key to determine randomly an order for each round and
> subsequently at run time dynamically modify these orders, employing
> e.g. certain values taken during the processing of the preceding
> block to do the modifications. In the same vein, the order of the round
> keys could be dynamically permuted at run time. That such dynamics
> would render analysis much harder seems evident, since it depends
> ultimately on the particular plaintext being processed and hence is
> unknown to the analyst. Note that all modifications mentioned above are
> "mild", for we don't change e.g. the values of the round keys as such
> but merely their order.
>
> Thanks.
>
> M. K. Shen
From: Mok-Kong Shen on 2 Mar 2010 17:23
unruh wrote:
> Mok-Kong Shen wrote:
>>
>> As I understand it, one main feature of the stream cipher RC4 is its
>> array S, which contains a randomly ordered alphabet [0..255] that is
>> dynamically modified via swapping of two of its elements each time a
>> symbol is being processed. Wouldn't dynamics also be advantageous for
>> block ciphers?
>
> That is in a sense what the various chaining modes try to give. But the
> problem is recovery from errors. If one byte of the encrypted text
> occurs, can the cypher recover from that and still decrypt the rest.
> If the algorithm itself is dynamic, this would seem to be impossible.
> The decryption of the current byte depends on all of the previous bytes.

I don't think the issue of technical errors is anything grave, given
today's hightech standard. For all transmission errors are well dealt
with in lower layers of protocol and computers are more reliable than
ever in my humble view. Or do you mean human handling errors? But
also an overwhelmingly large part of what was previously done by humans
in matters of communications has been taken over by machine and often
data entered by humans are checked for plausibility by machine.
Certainly the human factor can never be completely eliminated. But I am
of the humble opinion that one could neglect the disadvantages of
eventual consequences resulting from remaining chance errors in view of
the advantages achievable from (almost) full automation.

Thanks.

M. K. Shen

From: Mok-Kong Shen on 3 Mar 2010 05:05
Mok-Kong Shen wrote:
>
> ........... That such dynamics
> would render analysis much harder seems evident, since it depends
> ultimately on the particular plaintext being processed and hence is
> unknown to the analyst.[snip]

I think that such (proper, "inner" and rather simple to implement)
dynamics, plus further the possibility, as I recently suggested, of
employing the "outer" (being outside of the algorithm as such) dynamics
of changing keys (a master key generates the encryption keys for the
individual blocks using e.g. a block cipher in counter mode) for every
block, or after a number of blocks as dynamically determined by certan
values obtained during the processing of a preceding block, would
"fundamentally" foil the chance of any practical success of the
currently well-known analysis techniques, including the more recent
algebraic analysis.

M. K. Shen

From: biject on 4 Mar 2010 09:54
On Mar 2, 3:23 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> unruh wrote:
> > Mok-Kong Shen wrote:
>
> >> As I understand it, one main feature of the stream cipher RC4 is its
> >> array S, which contains a randomly ordered alphabet [0..255] that is
> >> dynamically modified via swapping of two of its elements each time a
> >> symbol is being processed. Wouldn't dynamics also be advantageous for
> >> block ciphers?
>
> > That is in a sense what the various chaining modes try to give. But the
> > problem is recovery from errors. If one byte of the encrypted text
> > occurs, can the cypher recover from that and still decrypt the rest.
> > If the algorithm itself is dynamic, this would seem to be impossible.
> > The decryption of the current byte depends on all of the previous bytes..
>
> I don't think the issue of technical errors is anything grave, given
> today's hightech standard. For all transmission errors are well dealt
> with in lower layers of protocol and computers are more reliable than
> ever in my humble view. Or do you mean human handling errors? But
> also an overwhelmingly large part of what was previously done by humans
> in matters of communications has been taken over by machine and often
> data entered by humans are checked for plausibility by machine.
> Certainly the human factor can never be completely eliminated. But I am
> of the humble opinion that one could neglect the disadvantages of
> eventual consequences resulting from remaining chance errors in view of
> the advantages achievable from (almost) full automation.
>
> Thanks.
>
> M. K. Shen

I most be getting to old or I read what you wrote wrong. Since I
think I agree with what you said. Or at least I agreed with what
I read as processed by my brain. Way to go.


David A. Scott
--
My Crypto code
http://bijective.dogma.net/crypto/scott19u.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"


 |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Generic Crypto APIs ?
Next: in ElGamal, could you hardcode the generator for a public key and not lose security?