![]() ![]() IRCYP XNVSF ERKMK MNJZZ ZTDBF / GMFBO JGADL KJSVG JKSGB JQFKU / FXWVS MWGKO CPKMQ KFDDR MRDSQ / OAOIU GAIRM ZZCBQ MEFMG ZVAOQ / QWJXN JENOF DBHVK Acknowledgements These points are shown below with the "/" symbol. This message was sent on 10th March 1944.Ī particular quirk on this network was that the Enigma machine operators manually advanced the left hand wheel (the reflector) one step after every 5th letter group. In general I avoid using on lists - just write map.The "Tirpitz" network was used for communication between the German and Japanese navies. May be more simply written as: all (`elem` letters) msgĪnd is a lot more readable. This expression: (and $ (`elem` letters) msg) The same same as the input ec except that the positions field has changed. Not only is it shorter, but it is also clearer that the returned value is This is (fortunately) close to the typical mathematical formulation, in which mappings are represented as a composition linear operators that permute the alphabet: The expression used in componentMapping to determine the mapping preformed by a component c that is in a given position p, is a bit more verbose than it needs to be: rotMap (1-p) letters !! (numA0 ch)) (rotMap (p-1) (wiring c))īut I was aiming to have something close the physical process by which rotating a component changes its mapping. In the context of a larger package, this would serve as an "internal" representation (that would have an inaccessible value constructor) and I would provide a more user-friendly "safe" constructor that parsed conventional specification strings. My type for the configuration, or state, of an Enigma machine, EmigmaConfig, will be unfamiliar to people who haven't though about the internals of how an Enigma works, and focuses on the minimal physical set of values that fully define it's state, rather than conventionally exposed things like the letters at the "windows". Since my goal is to be educational, and not to create a cryptographic tool, this is acceptable to me but comments about other approaches are welcome. This also lets me compute encodings by rotating mappings, which corresponds directly to what the Enigma machine is doing physically. Effectively, I determine what the encoding of every letter at every stage would be, and then use that to figure out how a given (single) letter is encoded. Overall, this is a bit (perhaps considerably?) less efficient that many alternative approaches might be, because rather determining encoding based only on a minimal state specification, I determine the complete mapping of each component of the machine as part of my encoding calculations. I'm also particularly interested review of following aspects: ![]() I'm also curious how clear the code - on its own, with out comments - is. I'm especially interested in review of any errors or missed opportunities to exploit Haskell features or idioms. Which can then be represented in one of the conventional ways: ghci> windows cfgĮxamined more deeply: ghci> putStr $ unlines $ stageMappingList cfgĪnd used to encode messages: ghci> let msg = "FOLGENDESISTSOFORTBEKANNTZUGEBEN" This code allows for the creation of a machine from a simple specification: ghci> let cfg = EnigmaConfig (I expect to post a follow on where a more complete package is reviewed but this should stand on its own.) As my first (keep that in mind!) Haskall program (full code at end) I've written a simple Enigma machine and would like feedback on the core code related to its stepping and encoding - stripped of comments to see how it fares without them. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |