Re: Enigma machine strenght using a computer


Simon Johnson wrote:
I personally think this is a silly requirement, no one algorithm can be
appropriate for a wide range of purposes (it doesn't mean that people
don't and won't try for it to be).

Why not? What is your justification for saying that we should not
develop one cipher that can be used everywhere?

For the same reasons pieces of software should be developped minimally
for specific needs instead of being standardized and bloated (used
Microsoft Word recently?). There's a market for everything I suppose.
Some will buy what is already there, some will have new products
developped. I have a tendency to think that a minimalistic approach to
requirements based on acutal needs is better than a set of requirements
that will apply to a wide range of applications. The reason for this is
that, usually, the cost for developping such products is much greater
than it has to be because more variables have to be taken into account.
You end up solving a problem that is greater than the actual scope. I
always thought it was a bad practice and I still do. The same idea
would apply to cryptography I would say. Many will disagree I'm sure.

This is akin to reusability in
programming. It really creates more problems (security problems in this
case) than not since a wider base uses the same algorithm.

If your
objective in using an algorithm is for it to fit and be quick to
execute on a smart card, then that's a different story, but one
shouldn't design an algorithm just because it should fit on a smart
card if somebody needs it to.

You offer no proof that security problems are intrinsically connected
to trying to create a single cipher that can run on multiple types of
hardware. AES is the advanced encryption standard in the United States
and elsewhere - it can run on everything from a smart-card to a
super-computer, and it's secure everywhere.

There's a synergistic effect in the case of cryptography. The fact that
the algorithm is widespread contributes to it being strong, no doubt
about that (this effect is very similar to open source programs. Since
the programs are out in the open for everybody to help, it definitely
makes them more robust). The security problem comes from the fact that
we have a non moving target. The algorithm is very well known and since
whoever knows what they are dealing with because of the widespread use
of this particular cypher, it seems to me to be easier to think of ways
to circumvent it, may it be just from knowing that a brute force attack
is not possible given a key strength threshold. There is no waste of
time, one knows exactly where to spend money to break the cypher
however money allows. That is the security problem, it becomes of a
different nature. It's a double edged weapon. A moving target is always
more difficult to wrap one's mind around than a static one. Money will
inevitably be spent to try and find a way to break a new encryption to
see if less money can be spent on reading encrypted messages.

There is no security penalty for designing a cipher which is usable in
resource starved set-ups.

Desktop computers don't suffer from the
same limitations embedded systems do, and as such, more robust
algorithms can be employed.


A cipher that is usable on a smart-card will generally offer amazing
performance on the desktop. This can only be good?

Sure, it can be, this is also beside the point. I'm not saying it's not
efficient, I'm simply objecting to having a static target and having
very far reaching requirements that don't apply to specific needs but
to vague generic needs.

Let me remind you again that AES runs well on smart-cards and is
secure. The same algorithm on the desktop operates faster than you can
write to most hard-disks.

It is therefore prudent to use the instructions provided by the
majority of CPUs that operate fastest.

This is why you see a lot of ciphers using XOR, ANDS, Circular shifts
and the like combined with table look-ups to provide security. They're
fast, compact and have well understood cryptographic properties.

They sure do, but I feel this is beside the point.

The reason AES is so fast on the desktop is because it uses such
operations. One of the reasons Rijndael was selected as the AES was
because it was faster than its competitors.

Performance is very important because performance costs money. How many
millions of dollars would have been wiped off the world economy if
Serpant had been chosen over Rijndael? (Actually, that's quite an
interesting question all by itself - any takers?)

I strongly disagree. Because something is the norm under the coupe of
some imaginary requirements doesn't mean it is superior. One can only
claim to be proud to be following the latest trend.

My requirements for a new cipher are as follows:

1. It's provably secure against all existing attacks.
2. It's faster than any cipher that satisfies 1. that currently exists.

3. It uses less memory than any cipher that satisifies 1. or 2.

That is a very tough set of requirements but if I'm to use your cipher
it clearly has to be better than what is already available. right?

I never gloated about my cypher being special or better, read other
posts I've written.

My current
implementation is not the fastest because it was designed at a high
level and because I didn't spend that much time on it (in any case, it
is well withing reasonable bounds for smaller text messages and given
the very large key space or about 4096 bits, the amount of rotors could
be reduced to considerably accelerate the algorithm without giving up
too much).

So I should trust the idea that rotors are better because you've
designed a cipher that uses them? Futhermore, by your own admission you
haven't spent much time on it!

I don't mean to be harsh here, but just because you designed a cipher
with a large key-space does not make it secure. Equally, just because
you decided to use rotors in that design does not make it a good idea
to use them.

I'm not an idiot Simon, I'm well aware of all this. As mentioned, I
never thought my algorithm was special in any way. I didn't ask anybody
to start using it and I certainly didn't think everybody would jump on
it because it was "my solution". I'm simply having fun with the
algorithm. I realize that many might come to this forum thinking they
found THE solution, but you shouldn't assume from the get go that
everybody is one of them. If you read the whole thread, you will notice
that the slip into an unexpected discussion wasn't of my doing. My
original question wasn't even close to how this thread turned out. It
wasn't trying to proposed my algorithm as a solution either, I was
simply asking a question.

The next step is to optimize the algorithm.

Be brave, be a scientist and show us your algorithm.

I would gladly output the algorithm to interrested parties, but I need
to clean it up first because it's not written in English, and also, I'm
thinking of bringing it down to C instead of using C++ (objects are
killing speed, but that last bit can be taken care of later).

[SNIP]

Regards
Jean-Francois Michaud

.