Re: Enigma machine strenght using a computer

Unruh wrote:
"=?iso-8859-1?q?Jean-Fran=E7ois_Michaud?=" <cometaj@xxxxxxxxxxx> writes:

Simon Johnson wrote:
They are complex in structure, but not complex to implement. They are
in fact very easy to implement in code. If they potentially allow for
very strong encryption even if they are slow, does it matter? It all
depends on the context in which it's used.

I can't speak for Unruh but I think the point he is making is this.

You're right that computers would allow us to implement an Enigma like
cipher with rotors that spin backwards, forwards, stop and start based
on other rotors, change their values according to the phase of the moon

But is this useful? Is this a good way to get security on modern

I think it can be useful. As I mentioned, it all depends on the

Electromechnical machines were used for encipherment because they made
encryption less error-prone and they were a cost effective way to get
security for their time.

Cryptography on modern hardware is all about getting the job done with
the fewest resources. A cipher that uses fewer resources can target a
greater number of platforms. If a cipher takes 4 gigs of RAM, it can't
be used on a smart-cart, for example, or mobile phones and things of
that ilk which all limit its usefulness.

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). 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. Desktop computers don't suffer from the
same limitations embedded systems do, and as such, more robust
algorithms can be employed.

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.

This makes these operations a superior foundation on which to construct
a cipher than a rotor based cipher design.

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 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). The next step is to optimize the algorithm.

But that is NOT what you are doing. You are taking an old technology and
stuffing it onto a modern computer. The encryption options are vastly
greater. YOu are creating a slow system, one which is know to be boken with
a reduced number of wheels (60 years ago). So your system is slow, highly
suspect. And you are chasing it why?

I simply because it is interresting, without pretention of it being the
panacea. Any encryption scheme is broken for somebody who has the
means. That is beside the point.

Also, stuffing "old" technology into a computer is not as bad an idea
as you seem to think. Reality is actually opposite to what you think.
Everything that we accomplish nowadays with computers is based on old
ideas or technologies. Computers simply allow us to do these things
better and faster through automation. The same can applies to the
reproduction of physical systems such as Enigma; better, faster. In any
case, my algorithm is inspired by the rotor machine, it isn't an exact
broken reproduction. Why are you getting so flustered about this? We're
just sharing ideas.

Also, we are considerably sliding away from my original question of
attributing lower and higher bounds in encryption strenght based on
algorithmic complexity using the output of another "rotor machine" to
determine which rotors and in which direction they will move (and which
rotors will be swapped). In this context, I'm assuming that the higher
bound is "as complex as we want".

Jean-Francois Michaud