Re: Enigma-like cipher: variable rotor stepping


David Eather wrote:
DarkProtoman wrote:
Jean-François Michaud wrote:
DarkProtoman wrote:
Jean-François Michaud wrote:
DarkProtoman wrote:
Jean-François Michaud wrote:
DarkProtoman wrote:
I'm writing an enigma-like cipher w/five rotors where adjacent rotors
rotate opposite direction of their neighbors and they have variable
stepping in which they step a number of times equal to the position of
the character they're on plus one, starting from zero, ie. in FOOD, F's
position would be zero, and the rotors would step once, on O they would
step twice, etc. Keeping w/ the fact that the first rotor would step
after every character, the second rotor would step when the first one
stepped 36 times,etc. How much more security would that give me over a
normal three rotor machine.
Hello DarkProtoman,

I'm actually working on something similar to you right now. It's funny
how Enigma like machines are resurfacing :). 5 rotos with 27 characters
(27 cogs) will give you 14348907 possible states to start from. If an
attacker had the algorithm, knowing how the rotors move, he could
probably brute force to try and figure out what initial state the
machine starts in, the way the rotors move is perfectly deterministic
from then on. I'm not certain how much stronger it would be, but I
don't think it would be much stronger.

I tried to circumvent that problem by going all out. I have 512 rotors
each with 256 cogs (extended ASCII set) which yields about 4096 bits of
strength (256^512 possible states to start from. It's probably overkill
and I'll probably shrink it down later). The way the rotors move is
actually controlled by another rotor machine with similar properties.
Some rotors go clockwise, some counter clockwise, some rotors are
swapped.

Look for the thread I started recently, we can bundle everything into
one and help each other ;-).

Regards
Jean-Francois Michaud
Which one is that? What language do you use? I use C++. I'll email you
my files. I don't have the patience to code 512 rotors. At the very
least, my system will prevent a Turing Bombe program from cracking it,
since the rotors step differently. And there's more characters for a
character to be encrypted as.
I used C++, but I'll be optimizing eventually because OOP isn't
appropriate for encryption.

I've coded the encrypting fn, could you code the decrypting one for me?
hehe I'm not going to code it for you but I can tell you what to do
;-). You need to do the exact opposite of what you're doing to
encrypt. In my case, since I'm XORing against the plain text, I can
simply XOR again to remove the encryption so the encryption and
decryption algorithm is the same.

I have no idea how to do that. All I know is that encrypting twice w/
the same settings doesn't bring you back to the original.
It depends how you implemented your machine. If the characters follow a
straight path downwards and if there's no reflector like in the
original Enigma, then for decryption, you have to start from the bottom
rotor instead of the top rotor to decrypt. Thats pretty much the only
difference. You definitely can't start from the top because then you're
following the path of encrypted characters instead of following the
path of plain text characters.

Regards
Jeff
So, just run it backwards, ie last instruction of the encrypting loop
first and vice versa?

Here's the code:

string Enigma::Encrypt(const string& cleartext)
{
string ciphertext;
ciphertext.resize(cleartext.size());
int i=0;
for(;i<cleartext.length();i++)
{
int val=Rotor::CharacterMap(cleartext[i]);
char val1=R1.GetCharacterIndex(val);
R1.AdvanceRotor((i+1)%36);
int val2=Rotor::CharacterMap(val1);
char val3=R2.GetCharacterIndex(val2);
if(R1.GetSteps()==36)
R2.ReverseRotor((i+1)%36);
int val4=Rotor::CharacterMap(val3);
char val5=R3.GetCharacterIndex(val4);
if(R2.GetSteps()==-36)
R3.AdvanceRotor((i+1)%36);
int val6=Rotor::CharacterMap(val5);
char val7=R4.GetCharacterIndex(val6);
if(R3.GetSteps()==36)
R4.ReverseRotor((i+1)%36);
int val8=Rotor::CharacterMap(val7);
char val9=R5.GetCharacterIndex(val8);
if(R4.GetSteps()==-36)
R5.AdvanceRotor((i+1)%36);
int val10=Rotor::CharacterMap(val9);
char val11=Ref.GetCharacterIndex(val10);
if(R5.GetSteps()==36)
Ref.ReverseRotor((i+1)%36);
int val12=Rotor::CharacterMap(val11);
char val13=R5.GetCharacterIndex(val12);
int val14=Rotor::CharacterMap(val13);
char val15=R4.GetCharacterIndex(val14);
int val16=Rotor::CharacterMap(val15);
char val17=R3.GetCharacterIndex(val16);
int val18=Rotor::CharacterMap(val17);
char val19=R2.GetCharacterIndex(val18);
int val20=Rotor::CharacterMap(val19);
char val21=R1.GetCharacterIndex(val20);
ciphertext[i]=plugboard(val21);
}
return ciphertext;
}
Hey Protoman,

Something I notice in your code, it looks like you're rotating the
rotors AS a character is going downwards. Is this correct? If this is
the case, then you can't mirror all the way back up since the rotors
have moved while the character is going downwards. This website
explains clearly, with graphics, how the machine worked. The last rotor
is a reflector and sends the character back upwards towards the
plugboard. I think your decryption problem lies in the rotors
revolving before the character is through all the way. This is why your
decryption doesn't work given idential initial settings. Also, you
might want to drop down the plugboard temporarilly to be able to debug
the rotor rotation + reflector first.

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

Regards
Jean-Francois Michaud

Can you explain in a little more detail? I can't figure out what you
mean.


If your doing a rotor machine on a PC you do not need a reflector. The
reflector only exists as a simple solution to a hardware problem. Dump
it and you also dump one of the weaknesses of enigma

It depends what he wants to do. If he wants to reproduce Enigma
exactly, including weaknesses then the reflector is necessary.
Otherwise, the suggesting is good.

(I still think the project is ill considered)

We already know what you think about the matter, beating the old horse
up one more time won't change anything.

Regards
Jean-Francois Michaud

.

Relevant Pages

  • Re: Enigma-like cipher: variable rotor stepping
    ... the character they're on plus one, starting from zero, ie. in FOOD, F's ... position would be zero, and the rotors would step once, on O they would ... appropriate for encryption. ... char val3=R2.GetCharacterIndex; ...
    (sci.crypt)
  • Re: Enigma-like cipher: variable rotor stepping
    ... the character they're on plus one, starting from zero, ie. in FOOD, F's ... position would be zero, and the rotors would step once, on O they would ... appropriate for encryption. ... char val3=R2.GetCharacterIndex; ...
    (sci.crypt)
  • Re: Enigma-like cipher: variable rotor stepping
    ... position would be zero, and the rotors would step once, on O they would ... rotos with 27 characters ... appropriate for encryption. ... char val3=R2.GetCharacterIndex; ...
    (sci.crypt)
  • Re: Mathematics of the Enigma cipher?
    ... A character is mapped to an integer which becomes ... All the Rotors should be advanced ... char val3=R2.GetCharacterIndex; ... I thought the Reflector was fixed. ...
    (comp.programming)
  • Re: Enigma-like cipher: variable rotor stepping
    ... position would be zero, and the rotors would step once, on O they would ... rotos with 27 characters ... appropriate for encryption. ... char val3=R2.GetCharacterIndex; ...
    (sci.crypt)