A Programming Enigma

[+Larry]

I have started working again on an old project of mine -- an Atari simulator version of the WWII Enigma cipher machine. I'm using BASIC XL, but as I see it now, porting it to Turbo Basic XL would not be much of an issue after completion of this version.

 

Here's my problem/question: My Enigma "machine" has 3 "rotors," each with 26 alpha characters, and each has it's own unique "wiring" that puts its alphabet in a particular order. When an input key is pressed, then rotor #1 indexes one position to pick up the next letter on the rotor. After rotor #1 has made one full revolution, then rotor #2 indexes one position. Then after rotor #2 has made one full revolution, rotor #3 indexes one position. (Much like a car's odometer.) Of course, there is much more to the "machine," but this indexing is a crucial part of getting it encoding/decoding correctly.

 

This indexing is a challenge -- I need a fast way to index that hopefully won't get too cumbersome. My initial solution is to have the "rotor" as a regular string of 26 characters and then use a small subroutine to "index" the string by re-writing it, temporarily saving the first character in the string and moving the next 25 characters up one position, and then taking the saved (first) character and making it character #26. Using strings, this is pretty quick.

 

But there are surely other ways to do this, and hopefully, better ones. I could use pointers, but I *think* that would get quite convoluted. A perhaps simpler way would be to use a large string made up of repeating segments of the 26-character "rotor". Then to index, I would just "move" the rotor (substring) up one position in the large string. That way, I would only have to reset my substring when I ran out of characters (infrequently).

 

Any suggestions for my Enigma enigma?

 

-Larry

Edited August 26, 2007 by Larry

[Heaven/TQA]

isn't there a simple maths solution for that? but i am not a maths guy... something like index=rotor1+rotor2*26+rotor3*26 (i am thinking of same like with the internal clock (zeropage 20,21,22). and by index div 26 it might be the correct index to the lookup table?

[Rybags]

Easiest way?

 

Probably to do it backwards.

 

Have the initial index equal to 25. Then just subtract 1 from INDEX1 each iteration (assuming INDEX1 for wheel 1, INDEX2 for wheel 2 etc)

 

Then, you just need a simple test:

 

INDEX1=INDEX1-1

IF INDEX1 THEN <skip to next iteration>

INDEX1=25:INDEX2=INDEX2-1

IF INDEX2 THEN <skip to next iteration>

INDEX2=25:INDEX3=INDEX3-1

IF NOT INDEX3 THEN INDEX3=25

<next iteration>

 

Use each INDEX variable to address a string containing the character sequence contained on each rotor (in reverse, since we're decrementing the index values).

Edited August 26, 2007 by Rybags

[deathtrappomegranate]

Easiest way?

 

Probably to do it backwards.

I wrote a series of similar programs back in the 80s, and this was the same method that I chose.

 

It was slow in Sinclair BASIC, but much faster (as is usually the case) in BBC BASIC. It's also very simple to implement in assembler, whether Z80 or 6502, and can then be much quicker.

 

Manipulating strings in BASIC tends to be slow; integer arithmetic is usually a better idea.

[Mathy]

Hello Larry

 

Why not use three strings, each with 26 characters in them. Then just manipulate the indexes.

 

I'm not sure if I understand how the enigma works (read: I have NO clue when these rotors are rotated), so I might be talking nonsense.

 

Greetings

 

Mathy

[Rybags]

http://en.wikipedia.org/wiki/Enigma_machine

 

Pretty reasonable description there.

 

Later variations introduced different stepping behaviour for the wheels (and more wheels).

[+Larry]

http://en.wikipedia.org/wiki/Enigma_machine

 

Pretty reasonable description there.

 

Later variations introduced different stepping behavior for the wheels (and more wheels).

 

Thanks to all for the suggestions. Yes, using indexes looks feasible to me.

 

There is a lot of info on the web about the Enigma, but the info at Wikipedia is among the very best that I've seen. I got interested in the Enigma several years ago when I saw a documentary on Public Television (or maybe the History Channel) about it. Since then, I've collected quite a bit of info.

 

-Larry

[a8isa1]

Here's my problem/question: My Enigma "machine" has 3 "rotors," each with 26 alpha characters, and each has it's own unique "wiring" that puts its alphabet in a particular order. When an input key is pressed, then rotor #1 indexes one position to pick up the next letter on the rotor. After rotor #1 has made one full revolution, then rotor #2 indexes one position. Then after rotor #2 has made one full revolution, rotor #3 indexes one position. (Much like a car's odometer.) Of course, there is much more to the "machine," but this indexing is a crucial part of getting it encoding/decoding correctl

Hi Larry.

 

As you know I'm not much of a programmer but this sounded like fun.

 

Below is my quick and dirty literal approach to simulating 3 code wheels.

 

10 DIM W1$(26),W2$(26),W3$(26),HOLD$(1),INDEX$(1),PAUSE$(1)

20 W1$="ABC":W2$=W1$:W3$=W1$:SIZE=LEN(W1$)

30 INDEX$="A"

40 ITERATION=0

100 REM MAIN BODY

110 ? "ITERATION=";ITERATION

120 ? "WHEEL 1 - ";W1$

130 ? "WHEEL 2 - ";W2$

140 ? "WHEEL 3 - ";W3$

150 ITERATION=ITERATION+1

160 GOSUB 1000

170 INPUT PAUSE$

180 GOTO 100

1000 REM INCREMENT WHEEL 1

1010 HOLD$=W1$(1)

1020 W1$=W1$(2)

1030 W1$(SIZE,SIZE)=HOLD$

1040 IF W1$(1,1)=INDEX$ THEN GOSUB 2000

1050 RETURN

2000 REM INCREMENT WHEEL 2

2010 HOLD$=W2$(1)

2020 W2$=W2$(2)

2030 W2$(SIZE,SIZE)=HOLD$

2040 IF W2$(1,1)=INDEX$ THEN GOSUB 3000

2050 RETURN

3000 REM INCREMENT WHEEL 3

3010 HOLD$=W3$(1)

3020 W3$=W3$(2)

3030 W3$(SIZE,SIZE)=HOLD$

3050 RETURN

 

The wheels have only 3 letters for now but they can be expanded by changing the init string. Wheels 2 and 3 are assumed to index on the same letter. At present the wheels increment AFTER the letter "A" returns to the first position.

 

If you wish wheel #2 to double increment, that is when wheel #3 increments (as mentioned in the wikipedia text), then add the following line:

 

3040 GOSUB 2000

 

Sample Output

 

- Steve

Edited August 27, 2007 by a8isa1

[peteym5]

If you get a working basic algorithm and know how it works, it should be easy to write up an assembly routine to do the coding/decoding part. Seems like it requires integer math and logic with no decimals, perfect for assembly. However Turbobasic on an Atari is pretty fast compared to anything that runs on a Sinclair, and you have an option to compile it.

[+Larry]

Hi Larry.

 

As you know I'm not much of a programmer but this sounded like fun.

 

Below is my quick and dirty literal approach to simulating 3 code wheels.

 

(snip...)

 

Hi Steve-

 

Thanks for the code. The concept looks very usable!

 

I've always enjoyed little "puzzles" like this rotor thing, and it's interesting how many different ways they can be solved!

 

-Larry

[+Larry]

Hello Larry

 

Why not use three strings, each with 26 characters in them. Then just manipulate the indexes.

 

I'm not sure if I understand how the enigma works (read: I have NO clue when these rotors are rotated), so I might be talking nonsense.

 

Greetings

 

Mathy

 

Hi Mathy (and anyone who is interested in the details of the Enigma rotors)-

 

This is the best description that I have found of the rotor details, including an example that you can trace through.

 

http://homepages.tesco.net/~andycarlson/en...ing_enigma.html

 

-Larry