Prev: Protecting 3x16 bits with 16 bits ? (Which error correcting code for mode 3?)
Next: why doesn't the decryption primitive in PKCS#1 employ RSA blinding?
From: J.D. on 15 Feb 2010 05:57
Oy. Let's try once more, shall we?

> I am afraid that you erred. S-boxs of DES are data dependent, because
> thier (the 4 inner input bits map to 4 output bits) selection depends
> on the two outer bits of the 6 input bits and therefore data dependent.

You are ascribing a significance to the distinction between "inner"
bits and "outer" bits that is entirely unwarranted. A DES s-box is a
function that maps 6 input bits onto 4 output bits. As such you can
select any two arbitrary bits out of the six input bits and then say,
"the mapping of the remaining four bits onto the four output bits
depends on these two bits" -- this statement is _exactly_ as true for
the two innermost bits as it is for the two outermost bits. There is
no distinction of kind that makes the two outer bits the 'selectors'
in any meaningful sense that could not apply equally to any other pair
of input bits.

My guess is that you looked at the DES s-box tables and thought that
because the outer bits determine the row while the four inner bits
determine the column that thus there is some difference of kind
between them. This is a misapprehension. The table is just how the
data is displayed. The exact same data (and hence the exact same
function) can be displayed in a different way; e.g. where the two
innermost bits select the row and the four outermost bits select the
column.

> But AES's ByteSub operates on a purely constant table and hence is
> "not" data dependent. (Or do you generally consider a substitution,
> e.g. the classical substitution, data dependent, simply because the
> outcome of the substitution, namely the output, "depends" on the
> data beind input? I certainly presume that's not the case.)

If you input the same 8 bits to the s-box of AES you will always and
in every case get the same 8 output bits. In exactly the same way and
for exactly the same reason, if you input the same 6 bits to one of
the s-boxes of DES you will always and in every case get the same 4
output bits. Similarly, if you input the exact same w + log2(w) bits
to the DDR function of RC5 (where w = the word length, e.g. 32) you
will always and in every case get the same w output bits. There is no
distinction between any of these functions that can support your
categorizing them as "fixed" and "variable" respectively.

> BTW, concerning the algebraic attacks you are interested in, I remember
> that very long time ago there were already attempts to attack DES with
> algebraic methods, but later I have never heard of them. Presumably
> it's (among perhaps other factors) the above mentioned "variable"
> nature of the S-Boxes of DES that hindered progress of these projects.
> I always wonder why the in my view superb idea of variable S-Boxes of
> DES apparently has not received serious considerations that it deserves
> in later generation of designs of block algorithnms.
>

As a rule of thumb, if you as a "layman" think you perceive something
that the entire expert community has missed, then it is very likely
that your perception is based upon a misunderstanding. This is not
always the case, but it is true often enough that such perceptions
serve very well as guides to further your own education in the topic:
i.e. "I think I see something everyone else has missed. But it is
much more likely I am misunderstanding something. Let me see if I can
figure out where I might be going wrong..."

From: Mok-Kong Shen on 15 Feb 2010 14:33
J.D. wrote:

> If you input the same 8 bits to the s-box of AES you will always and
> in every case get the same 8 output bits. In exactly the same way and
> for exactly the same reason, if you input the same 6 bits to one of
> the s-boxes of DES you will always and in every case get the same 4
> output bits. Similarly, if you input the exact same w + log2(w) bits
> to the DDR function of RC5 (where w = the word length, e.g. 32) you
> will always and in every case get the same w output bits. There is no
> distinction between any of these functions that can support your
> categorizing them as "fixed" and "variable" respectively.

But you wrote about the data dependent rotations of a cipher as
some specific feature of its design, didn't you? Now please kindly tell
what do you mean data dependency vs. data independency based on that
example. I guess that with the same way of argumentation you'll employ
I could also explain that the DES S-boxes "are" data dependent.

>> BTW, concerning the algebraic attacks you are interested in, I remember
>> that very long time ago there were already attempts to attack DES with
>> algebraic methods, but later I have never heard of them. Presumably
>> it's (among perhaps other factors) the above mentioned "variable"
>> nature of the S-Boxes of DES that hindered progress of these projects.
>> I always wonder why the in my view superb idea of variable S-Boxes of
>> DES apparently has not received serious considerations that it deserves
>> in later generation of designs of block algorithnms.
>>
>
> As a rule of thumb, if you as a "layman" think you perceive something
> that the entire expert community has missed, then it is very likely
> that your perception is based upon a misunderstanding. This is not
> always the case, but it is true often enough that such perceptions
> serve very well as guides to further your own education in the topic:
> i.e. "I think I see something everyone else has missed. But it is
> much more likely I am misunderstanding something. Let me see if I can
> figure out where I might be going wrong..."

If you are an expert, then refute my arguments of the futility of
the algebraic attacks in the case of unique key per each individual
block. Even in case you are not an expert but couldn't find any single
plausible reason against them, then I would in your place take time
to consider.

M. K. Shen


From: Greg Rose on 15 Feb 2010 18:34
In article <06233c9e-2fe7-4c09-9bd9-f80e106bb67b(a)x22g2000yqx.googlegroups.com>,
J.D. <degolyer181(a)yahoo.com> wrote:
>Oy. Let's try once more, shall we?

I wish you would stop playing with the troll.
This is exactly what he wants.

Greg.

--
Greg Rose
232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
From: J.D. on 15 Feb 2010 18:43
> I wish you would stop playing with the troll.

Sounds like a plan.

From: Mok-Kong Shen on 15 Feb 2010 19:17
J.D. wrote:
>
> Sounds like a plan.

My favourite citation for scientific discussions:

Was sich ueberhaupt sagen laesst, laesst sich klar sagen;

und wovon man nicht sprechen kann, darueber muss man schweigen.

L. Wittgenstein

M. K. Shen



First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Protecting 3x16 bits with 16 bits ? (Which error correcting code for mode 3?)
Next: why doesn't the decryption primitive in PKCS#1 employ RSA blinding?