Random Numbers, in two FIGnitions.

[Carl Attrill]

Hi Users!

This is going to be a Computer science 101 type question, but it is something I have pondered.

If I enter these words on two fignition computers at startup from cold would I get the same random number on each computer?

: seedon

seed @ 75 u* 75 0

d+ over over u< - - 

1 - dup seed ! ;

: rnd

seedon u*

swap drop ;

If I don't I would be interested in understanding why. 

If I do then I would like to know how more elaborate systems mix this it up a bit, as big data is reliant on public keys etc that seem to work very effectively.

I would dread to thing that major economies would be able to decrypt systems just by turning all the computers on and off again. 

Regards.

[Romilly Cocking]

Hi Carl,

I'll leave your Figgy question to my youngers and betters.

More elaborate systems get random seed values from various sources. Most Unix systems use things like mouse movements to create entropy. On an Arduino, you can get a random seed by doing an analogRead on a pin that is not attached to anything.

Regards,  Romilly

--
You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

@rareblog http://romillys-robots.blogspot.co.uk/

[Si Brindley]

Carl, I can't answer your question directly but it reminded me of something I learned just recently while reading Apple's Swift language reference….

There currently isn't a built-in pseudo-random number generator in Swift, so instead you can knock up a class that will do for most basic use cases:

 

class LinearCongruentialGenerator {

    var lastRandom = 42.0

    let m = 139968.0

    let a = 3877.0

    let c = 29573.0

    func random() -> Double {

        lastRandom = ((lastRandom * a + c) % m)

        return lastRandom / m

    }

}

 

 

As the class name implies this is what's knows as a "Linear congruential generator" and it lead me to read the fascinating Wikipedia article here:

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

 

It's simple and fast, only needing 32 or 64 bits to retain state… and it's random "enough" for trivial things like games.  (It's not random enough to run a lottery draw though, and if implemented badly patterns begin to emerge which belie the nature of the linear algorithm. There have been some massive mis-steps as a result of flawed historical versions!)

 

If memory serves correctly, some simple/early computers preferred to use a stored table of precalculated, high-quality random numbers, from which it would select based on a seed which was normally related to the time since the system was powered up.  In other words, the cycle count of the computer was the only entropy factored in.

 

I've used key-pair-generating functions that use other factors, such as the user's mouse movements, to increase entropy. I think TrueCrypt did this.

 

Probably doesn't help with your question but I thought it was interesting

 

 - Si

 

 

 

Carl Attrill wrote:

To: fignition@googlegroups com <fign...@googlegroups.com>

Subject: Random Numbers, in two FIGnitions.

From: Carl Attrill <carl.a...@gmail.com>

Reply-To: fign...@googlegroups.com <fign...@googlegroups.com>

Date: Tue, 29 Jul 2014 13:25:22 +0100

 

 

--

[Mark Wills]

It simply depends on what seed is,  or how it is initialised. If seed is (for example) the horizontal or vertical pixel clock then it is very unlikely that two Figgys would produce the same value as their displays would not be in sync with each other. If on the other hand seed is initialised to a known value on startup then you probably would get the same values.

[Carl Attrill]

Thanks for the replies, there are some interesting answers there, Si I will be sure to check out that wiki link very interesting.

entropy eh? 

So I guess I could make an extra word that would call the var of seed for seedon, this would change the value of the random number path the fignition would take, but again if this was implemented on two fignitions at the same time we would be back at square one.

I guess Mark and Romily have it by taking a snapshot value from something that could vary and then building a seed from that.

My limited understanding makes me think that this sort of technique would have suited the encryption/decryption on the enigma machine, providing you never turned them both off.

[Julian Skidmore]

Hi folks,

Once you understand entropy it's all downhill from thereon ;-)

-cheers from Julz

                             
                  The DIY 8-bit computer from nichemachines™

[carl]

The more I read about Numbers stations and one time pads the more I think that two FIGnitions (or any resettable devise that retains nothing on restart)  is a perfect encoding machine.

The seed could be set from any random source, then the rnd command can generate the code from there, the other devise simply un does this number generation to decode the data.

this is how the enigma machine worked right?

[Romilly Cocking]

The problem is that there are too few seeds: it would be very easy to crack using a brute force approach.

--
You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

@rareblog http://romillys-robots.blogspot.co.uk/

[Julian Skidmore]

Hi Carl/Romilly,

The enigma machine used a set (3 or 4) of fixed-mapping rotary encoders to encrypt data as well as a number of patch chords for some additional arbitrary mapping. Importantly, the encoders would never map any letter to itself. Therefore when a letter was encrypted it would be remapped by each rotary encoder in turn, then through the patch chords and then back through the rotary encoders before lighting up the encoded letter. And then the least significant rotary encoder would jump to the next setting (possibly shifting the next rotary encoder too etc) so that every letter would be scrambled through different paths the next time.

Enigma settings would change every day(?) and the settings would affect the order of the rotary encoders (which could be removed and swapped around) as well as the the initial rotation of each encoder as well as the patches.

In theory this made Enigma very secure due to the number of combinations, but of course it suffered from deficiencies, namely: (a) the 'never map to same letter' rule was exploitable (b) Its introduction in the 20s/30s in a simpler form gave Polish, then British intelligence about a decade to crack it and (c) Human carelessness often gave really helpful clues.

On the one hand, we ought to do better than an Enigma because we know it was possible to crack it using Bombe machines and I think even the Lorenz was cracked using Colossus and those valve devices didn't run all that quickly. On the other hand, there's no reason why we couldn't use 128bit keys on FIGnition and encrypt using, say AES encryption - not quickly of course, but for limited amounts of data it'd be possible.

On the first hand again, it'd be quite fun to write an Enigma simulator for FIGnition ;-)

-cheers from Julz

[Romilly Cocking]

If anyone wants to write one I have a Python Enigma emulator somewhere which I used on a TDD course for BBC engineers a while back.

You will need a known good software implementation as many of the ones on the web (and many published explanations of Enigma workings) are incorrect.

I'm pretty confident that mine works as it has correctly decoded real (and long) messages. The 'long' bit matters because the message needs to be long enough to test rotor rollover for each rotor.

There are actually two settings for each ring: an initial position, and an offset which affects rollover. 

Stepping and rollover are also more complicated than you might think. ISTR that they wee incorrectly described in Simon Singh's "The Code Book".

The patch cord mappings are not completely arbitrary; they  swap the pair of letters to which each cord is connected.

It would certainly be a fun FIGnition project :)

[Julian Skidmore]

Indeed, I neglected to clarify that patch cords swap letters; they're 'arbitrary' in the sense that you can pick which letter pairs should be swapped, though from my recollection of the description, there's only a limited number of patch cords (happy to be corrected here :-) ).

In addition although there might only be 4 rotary encoder rings in an enigma at any one time, there's a box with some additional rings you can substitute AFAIK.

Thanks for the info romilly! Looking forward to the python conversion :-)

-cheers julz

[Carl Attrill]

I have found an interesting site with further details about the Enigma, Romily, I am not sure if the emulator there is one of the ones you say are inaccurate. Looks like you use three wheels and an optional plugboard matrix to further confuse things.

The static wheel would not be required, the reflector could be of two variants, I see all these stages as forth words.

http://enigma.louisedade.co.uk/howitworks.html

I would be interested in helping with this, but I am pretty sure that the listing will be more efficient from you guys in the end.

Perhaps to proof in the pudding would be to write a program and then post it with the key here and wait for the decoded message.

There is also a Daily Key generator http://enigma.louisedade.co.uk/dailykeys.html

[Julian Skidmore]

Aaaah, it'd be quote interesting to come up with independent implementations and see if they talk to each other :-)

Cheers julz

[carl]

Team enigma :-)

Is there any source anywhere that publishes what the internal wheel connections were? there is a DIY kit but it does not make that part clear, alternatively would it be as good to make a new standard, seeing that our character set may differ from the original a little anyway.

I guess this would be a good time to start to understand mod (modal) and how to execute it, can anyone give me an example of usage? would I need an array first.

i.e. wheel1  in ASCII 65,66,67,68,69,70,71

69 + 3  mod

= 65   

? is this right.

-Carl

 

[Romilly Cocking]

I haven't yet found my complete simulation code (it's in a tarred backup somewhere) but this (below) will give you the mappings for eight rotor types and two reflectors.

rotorMaps =    dict(

      #                ABCDEFGHIJKLMNOPQRSTUVWXYZ

                I=    "EKMFLGDQVZNTOWYHXUSPAIBRCJ",

                II=   "AJDKSIRUXBLHWTMCQGZNPYFVOE",

                III=  "BDFHJLCPRTXVZNYEIWGAKMUSQO",

                IV=   "ESOVPZJAYQUIRHXLNFTGKDCMWB",

                V=    "VZBRGITYUPSDNHLXAWMJQOFECK",

                VI=   "JPGVOUMFYQBENHZRDKASXLICTW",

                VII=  "NZJHGRCXMYSWBOUFAIVLPEKQDT",

                VIII= "FKQHTLXOCBJSPDZRAMEWNIUYGV")

reflectorMaps = dict(

                  B=   "YRUHQSLDPXNGOKMIEBFZCWVJAT",

                  C=   "FVPJIAOYEDRZXWGCTKUQSBNMHL")

It's Python code; it shows that for a type I rotor, A is mapped to E, B to K and so forth.

You'll find  (a lot) more info here: http://www.cryptomuseum.com/crypto/enigma/wiring.htm

I'm confused by your question about mod. Are you asking about the definition of mod (modulus)?

--

You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

@rareblog http://romillys-robots.blogspot.co.uk/

[Julian Skidmore]

Forward translation, e.g.:

0 bytes rotorI " EKMFLGDQVZNTOWYHXUSPAIBRCJ "

0 bytes rotorII "AJDKSIRUXBLHWTMCQGZNPYFVOE "

etc

then a forward translation from one to the next with fixed rotors:

: mapForward ( ch -- ch)

  asc A - rotorI

  asc A - rotorII

  ..

;

-cheers from Julz

[carl]

Thank you Romilly/Julz

Thats exactly what I was after.

I think I mean modulus, because when a letter is pressed the wheel moves one, I would imagine that the last item in the list should wrap around and go to the top. Then when this is done >26 times the second wheel then moves one at the same time and so on. 

Lots on the go at the moment in life, but still think about FIGnition problems when I have the time!

Carl.