Re: Enigma machine strenght using a computer

On 30 Dec 2006 19:10:56 GMT, Unruh <unruh-spam@xxxxxxxxxxxxxx> 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
etc..

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

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

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?


Arguably the primary function of the German Enigma cipher was to
authenticate radio messages. Radio messages received scrambled with
the German day key would more likely have been sent by German radio
operators.

Back in WW2 radio communications were often difficult to authenticate
by sender position. It would have been possible for the enemy to send
a phony message if communications were unencrypted.

Even though the Enigma enciphered transmissions could be broken back
on the greene at Bletchley the Germans knew this would take some time
and hoped it would take long enough so that the day key would not be
compromised and used to create a counterfeit message.

The analog these days is point of sales authentication. You can limit
the amount of time an intruder has to steal or break the
authenticating key that secures the transaction.

For higher security needs solutions like IPV6 and modern methods like
closed loop quantum cryptography give better security.
.

Relevant Pages

  • Re: New Encryption Idea
    ... long before the 66.7 years you have claimed, this is a very real security ... so your algorithm is at best redundant. ... > time (it can take more in the MEAS encryption mode). ... RSA won't have the pRNG requirements ...
    (sci.crypt)
  • Re: Enigma machine strenght using a computer
    ... cipher with rotors that spin backwards, forwards, stop and start based ... Is this a good way to get security on modern ... encryption less error-prone and they were a cost effective way to get ... I personally think this is a silly requirement, no one algorithm can be ...
    (sci.crypt)
  • Re: SPES (my new encryption) one of its kind
    ... with provable security properties rather than a system very difficult ... 1- can you name an encryption system which has provable security? ... an AES128 is far more secure than a Vingenere cipher even with a MB ... may not say that a block cypher used in CTR mode is stupid!) ...
    (sci.crypt)
  • Re: Enigma machine strenght using a computer
    ... cipher with rotors that spin backwards, forwards, stop and start based ... on other rotors, change their values according to the phase of the moon ... encryption less error-prone and they were a cost effective way to get ... case) than not since a wider base uses the same algorithm. ...
    (sci.crypt)
  • Re: Enigma machine strenght using a computer
    ... cipher with rotors that spin backwards, forwards, stop and start based ... Is this a good way to get security on modern ... encryption less error-prone and they were a cost effective way to get ... I personally think this is a silly requirement, no one algorithm can be ...
    (sci.crypt)