Re: Encryption types

On Jun 3, 6:38 pm, Peter Fairbrother <zenadsl6...@xxxxxxxxx> wrote:
Jeffrey Goldberg wrote:
On 11-06-03 2:19 PM, Peter Fairbrother wrote:
Paul Rubin wrote:

In the case of block ciphers (treated in the paper) the folk theorem
isn't wrong as long as one of the ciphers in the cascade (no matter what
position) is strong.  In the paper's example, both ciphers were weak,
in a way that interchanging them made a difference.  
As I recall, they claimed both ciphers were strong, or that at least one
of them was - can't remember exactly now, and it doesn't really matter
to my point.

The ciphers involved only had four keys, so their definition of "strong"
isn't necessarily what we might call strong - there are many ways to
mathematically express the ciphers used so they can be manipulated in
O(n) work, which isn't (or shouldn't be) true of a real block cipher.

One of the ciphers preserved some statistical artifacts of the input,
the other one didn't. When the "weak" one was first, the whole cascade
was was weak, certainly weaker than the "strong" cipher. But when the
"strong" one went first, the whole cascade remained at least as strong
as the "strong" cipher.

yeah, but any of does this matter at all? The work involved to break any
of the ciphers is tiny - and it doesn't scale, it's O(n) at best. And
that's not good enough for a modern cipher, full stop,

So for a modern secure cipher (which can't have only four keys, that
would be wildly insecure) that attack simply doesn't work.

Example, Wiles, and Fermat - things which are true for n=2. like
fermat's last theorem, are not necessarily true for n=3.

And for n=2^128, or better 2^256, they may be, and in this case usually
are, very untrue indeed.

How usually? Brute force is quicker if the two ciphers have different
mathematical structures. Defining that - which is the common wisdom
after all - isn't easy, but it says cipher 1 isn't -

Well, for a start, let's say that the keypermutations of one those
ciphers are random, ie that one of these ciphers is secure.

Now, how likely is it that the other one's keypermutations weakens that

Let's start with some assumptions, for instance thatThere are n!
possible permutations for a cipher with block size n, so after

none of the keypermutations of cipher 1 are (anti)- or keypermutations
of cipher 2, and

I think that people are underrating the importance of the paper. Of
course we expect that our modern ciphers aren't weak in the way of the
one used to demonstrate the point.  But the folk wisdom that it is
challenging isn't saying "a cascade of /strong/ ciphers is at least as
strong as the strongest of them". It is claiming, falsely, that "A
cascade of ciphers is at least as strong as the strongest one"

Within certain constraints, the folk wisdom claim *is* probably actually
true. It only isn't true if the block size is small. or if one ipher
somehow decrypts another

nah. I lost the plot here, or perhaps somewhere a bit before I wrote
this. Make of this as you wish, I hope the idea is in there to be seen,
or you could ask me tomorrow.

Love to you all,

-- Peter Fairbrother

If you know that your ciphers are strong, then there is no point in
cascading (other than giving you a way to increase key length).

we'd all agree that cascading doesn't effectively increase key length.


motivation for a cascade is the potential that one of the ciphers may
turn out to be not as strong was we currently believe it to be.


So if it turns that that you have a cascade, and the first cipher turns
out that the first cipher reflects some statistical artifacts of its

er, no, there's nothing like that in the paper afaicr.

But I haven't read it in quite a while, and I think you are just

in a way that we don't know yet, then it is possible that the

cascade is only as strong as that first weak one.



Perhaps my last posting here seemed somewhat harsh but giving an
example of increased difficulty in solution from the addition of even
a classical algorithm in a cascade is rather simple to do, certainly
if parlor rules are violated.