Enigma. Gruppe: E4-105

Transkript

1 Enigma Gruppe: E4-105

2

3 Department of Computer Science Fredrik Bajers Vej 7 Telefon Fax Titel: Enigma Tema: Et større program Synopsis: Projektperiode: SW3, efterårssemesteret 2004 Projektgruppe: E4-105 Deltagere: Henrik Kragh-Hansen Jeppe Vestergaard Boelsmand Rasmus Dichmann Carlsen Rasmus Thorslund Jensen Adam Masoudn Tharaniharan Somasegaran Vejleder: Keld Pedersen Oplagstal: 8 Denne rapport omhandler Enigma maskinen, som blev brugt af tyskerne under anden verdenskrig. Der vil blive fokuseret på, hvordan en Enigma virker rent teknisk. Efter vi har beskrevet, hvordan en Enigma maskine virker, vil vi gennemgå det program, vi har udviklet, som kan simulere den Enigma, der blev brugt under anden verdenskrig. Vi vil desuden implementere en række ekstra features, så vores Enigma bliver mere dynamisk, og gør det nemmere, at sende chifrerede beskeder mellem to brugere, der begge har en udgave af vores Enigma program. Der vil blive udviklet et Command Line Interface (CLI), så vores program kan anvendes med kommandoer, og der vil blive udviklet et Graphic User Interface (GUI), hvor brugeren vil have adgang til avancerede features gennem en grafisk brugerflade. Sidetal: 96 Bilagsantal og art: 7 sider og 1 cd Afsluttet den 17. December 2004

4 Forord Denne rapport er udarbejdet ved Aalborg Universitet under studieretningen Softwareingeniør. Projektet er udarbejdet i projektperioden 2. september til 21. december Denne rapport omhandler den tyske Enigma cipher maskine, der blev anvendt af tyskerne under anden verdenskrig. Det forventes ikke, at man allerede kender til hvordan en Enigma maskine virker, da dette bliver forklaret i rapporten. Rapporten henvender sig til personer, der har interesse i, hvordan den tyske Enigma virker. Vi vil gerne takke Peter Axel Nielsen for lån af hans Enigma maskine, og Keld Pedersen for hans gode vejledning. Kildehenvisninger skrives med kantede parenteser [nummer på kilden], som refererer til en litteraturliste, der kan findes bagerst i rapporten. Når vi i rapporten skriver han eller hun, så mener vi han/hun. Kildekode forklaret i teksten vil være linieombrudt, og vil til tider ikke ligne det originale. Dette skyldes diverse kommentarer, som måtte være skrevet i kodefilerne og problemer med kodeopsætninger, som ikke vil være hensigtsmæssige at have med i rapporten. For at forstå koden, skal man kunne forstå objektorienteret programmering (OOP) og Java. Jeppe Vestergaard Boelsmand Rasmus Thorslund Jensen Tharaniharan Somasegaran Adam Masoudn Rasmus Dichmann Carlsen Henrik Kragh-Hansen i

5 Indhold 1 Indledning Enigma historie Beskrivelse af Enigma Stecker Rotor Indikator Ringopsætning Reflektor Eksempel på chifrering med Enigma Kravspecifikation kvalitetsmålskema Udviklingsmodeller Vandfaldsmodellen Evolutionær model Fjerde Generations Teknikker Spiral Model Valg af udviklingsmodel Design Enigma Components Stecker Reflector Rotor Enigma Dataminer WriteXML Config Alphabet Util XML standard ii

6 INDHOLD 5.2 Designet af den Grafiske Brugerflade Program layout Enigma vinduet Simpel Opsætning Vinduet Avanceret Vinduet Alfabet Kommando Brugerflade Argumenter Anvendelse af Brugerfladen Ekstra features i vores Enigma Kodebeskrivelse Kode standard Enigma kodebeskrivelse GUI kodebeskrivelse CLI kodebeskrivelse Testning Enigma test Unit tests Integrations tests GUI test Første fase Anden fase Tredje fase CLI test Konklusion på testning Evaluering af anvendte værktøjer Planlægning Versionsstyring Programmering Test metoder Konklusion Litteratur 81 A Kilde Kritik 82 B Værktøjs evaluering 84 C Planlægning 85 iii

7 Figurer 2.1 Abstrakt figur af Enigma Et eksempel på en stecker Oversigt over de originale rotorer Rotor 2 detaljeret Rotor 2 efter en rotation Forklaring af reflektor B Eksempel på chifrering af HELLO ENIGMA Vandfaldsmodellen Evolutionær model Overordnet model for fjerde generations udviklingsmodeller Spiral model Overordent design af vores program UML diagram af vores Enigma design Diagram over inputet til vores WriteXML Overordnet sturktur af vinduer, og deres sammenhæng Hovedvinduet Simpel Avanceret Alfabet vinduet UML diagram af vores Command Line Interface design Eksempel på chifrering af input Kontrol Flow Diagram Eksempel på chifrering af HELLO ENIGMA med GUI iv

8 Tabeller 2.1 Placeringen af notches på rotorerne Hvilke par der er på de tyske reflektorer Kvalitetsmål Variabler i alfabet klassen Alfabet konstruktøren Undersøger alfabetet for duplikerede bogstaver Finder pladsen af et bogstav Finder bogstavet på den givne plads cipher metoden i Enigma.java subcipher metoden i Enigma.java cipher metoden i Components.java cipher metoden i Rotor.java Tilføje en label til BorderLayout Tilføje en label til GridBagLayout Action i GUI Kommunikation med brugeren i CLI Testcases Kontrolstruktur v

9 Kapitel 1 Indledning Under første verdenskrig anvendtes morsekode til transmission af beskeder. En svaghed ved denne metode var, at alle som opfangede beskeden, og som kendte til morsekoden, kunne forstå beskeden. Derfor var det ikke så praktisk anvendeligt, for virksomheder som gerne ville beskytte sig imod industrispionage. Værre var det dog for militæret, hvor slagets succes afhang af beskedernes sikkerhed. Der blev derfor efterlyst en metode til at gøre kommunikation sikker på, og en løsning kom i form af Enigma maskinen. Denne rapport vil beskrive Enigma maskinen og dens funktionalitet, og chifrerings metoden gennemgås og analyseres. Derudover implementeres denne maskine i det objektorienteret programmeringssprog Java. Hovedvægten af rapporten vil ligge i programmet, beskrivelse af programmet og selve udviklings forløbet. 1.1 Enigma historie Enigma maskinen var oprindeligt udviklet til anvendelse indenfor industrien, for virksomheder, der havde brug for sikker kommunikationslinie, som samtidigt var let anvendeligt. Den blev opfundet og produceret af Arthur Scherbius, en tysk ingeniør. Enigma maskinen var så effektiv, at den hurtigt tiltrak det tyske militærs opmærksomhed. Det er som chiffer maskine i det tyske militær under anden verdenskrig, at Enigma er bedst kendt. Inden det tyske militær tog den kommercielle Enigma i brug, modificerede de den for at opnå endnu højere sikkerhed, men i det store hele fungerede maskinen på samme måde. En anden feature, som tiltrak det tyske militær, var størrelsen på Enigma maskinen. Den var transportabel, hvilket gjorde den ideel til blitzkreig strategien, hvor det var livsnødvendig med en perfekt koordinering imellem luft og jord styrkerne. Det tyske søværn gjorde også megen brug af Enigma maskinen. Især i ubåde var den et vigtigt værktøj, til at angive positioner på fjendtlige skibe og konvojer. På denne måde kunne ubådene koordinere 1

10 KAPITEL 1. INDLEDNING deres angreb, og derved forvolde størst skade. Tyskerne overvurderede dog graden af Enigmaens chifreringsevne. De var overbeviste om at koden var ubrydelig. De første som tog kampen op mod Enigma maskinen var Polen. Det polske dechifrerings bureau, BS4, opsnappede en af det tyske militærs Enigma maskiner, som var sendt til den tyske ambassade i Polen. De sendte pakken videre til den tyske ambassade, så de ikke ville fatte mistanke, men BS4 nåede at få undersøgt Enigma maskinen så omhyggeligt, at de var i stand til at duplikere den, samt dechifrer nogle tyske beskeder. I 1938 foretog tyskerne nogle ændringer i Enigma maskinen, bl.a. udvidede de systemet med to rotorer, så at der nu var fem i alt. Enigma maskinen kan indeholde tre rotorer, men når der var fem rotorer at vælge mellem, gjorde det koden endnu mere kompliceret, og polakkerne havde på det tidspunkt ikke ressourcer til, at fortsætte med dechifreringen af Enigma maskinen. Tyskerne chifrere de beskederne efter en forudbestemt dagsopsætning for rotorerne, reflektoren og steckeren. Derudover valgte operatøren, tre bogstaver som fungerede som tekstindstillingen for den pågældende kodningssession. Disse tre bogstaver blev skrevet to gange i starten af teksten med dagsopsætningen, og resten af koden blev chifreret med henhold til de tre bogstaver. Til sidst blev de tre bogstaver igen skrevet to gange med dagsindstillingen. Hvis man ikke er i besiddelse af dagsopsætningen, krævede det, at tusinder af forskellige opsætninger af Enigma maskinen skulle afprøves, for at gætte opsætningen. Til dette formål opfandt de allierede The Bomb. The Bomb bestod af 36 rotorer. Disse repræsenterer 12 Enigma maskiner hver med tre rotorer. Disse rotorer havde den samme tilslutning, som rigtige Enigma rotorer, og kunne på samme vis udskiftes. Så testede The Bomb alle muligheder for en korrekt enigma opsætning, og når maskinen landede på en sandsynlig opsætning, stoppede den, og den mulige dagsopsætning for beskeden kunne så verificere manuelt på en Enigma maskine. Afsnittet er skrevet ud fra hjemmesiderne About the bomb [2] og Enigma Applet [1]. 2

11 Kapitel 2 Beskrivelse af Enigma Dette kapitel vil først beskrive, hvordan Enigma maskinen teoretisk fungerer, derefter tilgå problemet mere direkte, og gennemgå et eksempel. Figur 2.1: Abstrakt figur af Enigma Figur 2.1 er en overordnet illustration af, hvordan chifreringen initialiseres. Enigmaen får et bogstav som input, som sendes igennem steckeren, som beskrives i afsnit 2.1, hvor bogstavet bliver ændret. Derefter igennem de tre rotorer, som beskrives i afsnit 2.2, hvor hver rotor ændrer bogstavet. Herefter ændrer reflektoren bogstavet, som beskrives i afsnit 2.5, og sender det retur gennem de tre rotorer, hvor det igen bliver ændret til et nyt bogstav efter hver passage. Sidst, men ikke mindst, går bogstavet gennem steckeren og returnerer det chifrerede bogstav. Sammenlagt skifter bogstavet tilstand ni gange inden det returneres til brugeren. Det næste afsnit vil redegøre for, hvad der sker i de enkelte bestanddele af Enigmaen, dvs. steckeren, rotorerne og reflektoren. 3

12 KAPITEL 2. BESKRIVELSE AF ENIGMA 2.1 Stecker En stecker virker som et omstillingsbord for tastaturet, brugeren kan opsætte steckeren, før Enigmaen tages i brug. Steckeren bytter om på bogstaverne i par. Brugeren sætter to bogstaver sammen, f.eks. kan H sættes sammen med G. Dvs. når brugeren taster H ændrer steckeren det til G, og omvendt når der tastes G ændres det til H. Det er muligt at sætte steckeren op for dele af, eller for hele alfabetet, men det er ikke nødvendigt for at anvende Enigmaen. Der eksisterer ikke nogen standard stecker opsætning, da dette var noget, der blev sat op ud fra dagsopsætningen, som blev beskrevet i Enigma historie. Figur 2.2: Et eksempel på en stecker På figur 2.2 illustreres en opsætning af steckeren. I Enigma maskinen er der to normale alfabeter under hinanden, og parrene forbindes med ledninger, men for at gøre det mere overskuelig, er det bogstav som inputtet skal chifreres til placeret under det normale alfabet. Det danner følgende par: (BI), (CS), (EJ), (FX), (GH), (KZ), (MV), (NT), (OR), (PU), (QW) Følgende bogstaver chifreres ikke: A, D, L, Y. Herefter følger en beskrivelse rotorerne. 2.2 Rotor Rotorer chifreres ikke par, men ikke desto mindre ændrer den ligesom steckeren bogstavet til et nyt bogstav, men hermed ophører alle lighederne. Når et input er chifreret, roterer rotoren, således at hvis den modtog to ens input, vil outputtet ikke være ens. På figur 2.3 ses de originale rotorer, der blev anvendt af tyskerne under anden verdenskrig. Rotor 1-5 er dem, som kan benyttes i en standard Enigma, og rotor 6-8 blev kun anvendt i den Enigma, som den tyske flåde benyttede sig af. Flåden havde også en version af Enigma maskinen 1, der kunne indeholde 4 rotorer, og den sidste rotor bestod af enten Beta eller Gamma rotoren. På figur 2.4 ses rotor 2, hvor det ses, hvordan de forskellige bogstaver bliver forbundet. Figuren har samme forbindelser, som rotor 2 har på figur 2.3, hvis G er input og stregen følges, så vil der returneres et R, hvilket er det samme som på den forrige figur. Problemet med figur 2.3 er, at det er svært at overskue, hvad der sker når rotoren roterer. 1 Der blev kaldt Shark 4

13 KAPITEL 2. BESKRIVELSE AF ENIGMA Figur 2.3: Oversigt over de originale rotorer Figur 2.4: Rotor 2 detaljeret Figur 2.5: Rotor 2 efter en rotation Figur 2.5 illustrerer et eksempel på, hvordan rotoren ser ud efter en rotation. Hvis inputtet igen er G, så ses det, at G linker til H, og hvis strengen følges, så hænger H sammen med U og U linker til T, hvilket resulterer i at G 5

14 KAPITEL 2. BESKRIVELSE AF ENIGMA returnerer et T, når rotor 2 er roteret en position. Tilsvarende sker i de andre rotorer. Den første rotor i Enigmaen roterer hver gang, den modtager et bogstav, hvorimod de andre rotorer kun roterer, hvis den forrige rotor står i notch eller de selv står i notch. Som tidligere illustreret på figur 2.1, kan rotorerne også chifrere bagfra. Når et bogstav passerer baglæns gennem en rotor, så svarer det til at chifrere nedefra og op på figur 2.5. Her vises, hvordan O chifreres på vej tilbage gennem rotor 2. O rammer op på P, og hvis stregen følges, så hænger P sammen med U, da der læses nedefra og op. U trykker derefter op på T, hvilket vil sige, at O returnerer et T, når rotor 2 er roteret en position, og bogstavet chifreres på vej tilbage gennem rotoren. På tabel 2.1 ses det, hvor der er notches på de forskellige rotorer. På Beta og Gamma rotorerne er der ikke notches, da disse rotorer altid skal være placeret længst til venstre, som sidste rotor, og de kan derfor ikke påvirke andre rotorer. Beta og Gamma rotorerne kan heller ikke roteres af andre rotorer. Rotor 1 Rotor 2 Rotor 3 Rotor 4 Rotor 5 Rotor 6,7 og 8 på R på F på W på K på A på A og N Tabel 2.1: Placeringen af notches på rotorerne 2.3 Indikator Det er vigtigt, at hver rotor står på samme måde, når der chifreres og dechifreres. Dette sikres ved hjælp af indikatoren. Indikatoren viser, i hvilken position hver rotor står, ved at vise et bogstav. Den har 26 mulige positioner den kan stå på, nemlig bogstaverne fra A til Z. Disse bogstaver er skrevet på ringen, se afsnit 2.4. Hver gang en rotor roterer skifter bogstavet i indikatoren. 2.4 Ringopsætning Ringen sidder omkring selve kernen af hver rotor, hvor kernen indeholder de krydsende ledninger, der bytter om på bogstaverne. Den kan ved hjælp af en tap og en bladfjeder låses fast på rotoren i en bestemt position, inden chifreringen begynder. Fordi de notches, der tvinger rotoren ved siden af til at rotere, sidder på ringen, er det ringen der bestemmer, hvornår rotoren skal rotere. Samtidigt sidder indikatorbogstaverne også på ringen. Derfor vil en given rotor altid rotere ved samme bogstav, uanset hvordan ringen er forskudt. Af samme grund kan brugeren derfor ikke umiddelbart se, hvordan 6

15 KAPITEL 2. BESKRIVELSE AF ENIGMA ringen er sat. Det eneste den gør, er at forskyde indikatoren i forhold til kernen. Derved gøres rotoren på en nem måde mere kompliceret. I næste afsnit vil der blive gennemgået, hvordan reflektoren fungerer. 2.5 Reflektor En reflektor chifrerer i form af par i stil med steckeren, forskellen ligger hovedsagligt i, at en stecker sender bogstavet igennem, hvor en reflektor sender bogstavet tilbage, så der bliver tale om et kredsløb. Tabel 2.2 viser en oversigt over de reflektorer, som tyskerne brugte i anden verdenskrig. Navn B C B Dünn C Dünn De par reflektoren har (AY)(BR)(CU)(DH)(EQ)(FS)(GL)(IP)(JX)(KN)(MO)(TZ)(VW) (AF)(BV)(CP)(DJ)(EI)(GO)(HY)(KR)(LZ)(MX)(NW)(TQ)(SU) (AE)(BN)(CK)(DQ)(FU)(GY)(HW)(IJ)(LO)(MP)(RX)(SZ)(TV) (AR)(BD)(CO)(EJ)(FN)(GT)(HK)(IV)(LM)(PW)(QZ)(SX)(UY) Tabel 2.2: Hvilke par der er på de tyske reflektorer Figur 2.6: Forklaring af reflektor B På figur 2.6 ses det, hvordan reflektor B linker de forskellige par sammen. Hvis bogstavet E rammer reflektoren, så chifreres det over til Q. Da reflektoren kobler bogstaverne sammen i stil med en stecker, så gælder det modsatte også, så Q chifreres til E. Der vil nu blive beskrevet et eksempel på, hvordan en sætning chifreres ved hjælp af Enigma maskinen. 2.6 Eksempel på chifrering med Enigma Dette afsnit vil tydeliggøre hvorledes Enigma maskinen chifrerer ved at gennemgå et eksempel skridt for skridt, men først skal Enigmaen sættes op. Først gennemgås opsætningen. Vores ring og indikator opsætning er sat til 111 og AAA, hvilket vil sige, at der ikke er nogen forskydning af hverken notches eller rotorer, når Enigmaen først begynder at blive anvendt. Der bruges rotor 1, 2 og 3. Rotorerne er sat op så bogstavet først chifreres af rotor 2, så 1 og til sidst 3. Den reflektor, der er valgt, er reflektor B, og som 7

16 KAPITEL 2. BESKRIVELSE AF ENIGMA stecker er der valgt den, som er blevet gennemgået i afsnittet vedrørende steckeren, og som kan ses på figur 2.2. Ring: 111 Indikator: AAA Rotor Reflektor B Stecker: (BI), (CS), (EJ), (FX), (GH), (KZ), (MV), (NT), (OR), (PU), (QW) Følgende bogstaver chifreres ikke af steckeren: A, D, L, Y. Enigma maskinen er nu sat op, og er klar til at chifrere en besked. Det der skal chifreres er: HELLO ENIGMA, der resulterer i følgende output NCGDNPHKYVL, med den valgte opsætning. Den originale Enigma maskine kunne ikke håndtere mellemrum, hvilket er grunden til, at outputtet står som ét ord. Herunder illustreres hvorledes H bliver chifreret til N. H skifter bogstav på følgende måde inden et N bliver returneret: H->G GHUT TTPP PPEE E->Q QQYY YYOO OPUT T->N Først går H gennem steckeren og bliver til G, som vist på side 4, som ses ved H->G. GHUT viser, hvordan G skifter til T ved at gå gennem rotor 2, som blev gennemgået på side 6. TTPP viser, hvordan T bliver chifreret gennem rotor 1, da rotoren ikke er roteret rammer T direkte ned på T, som viste ved eksempel på side 4. Tilsvarende sker i rotor 3, og derefter chifreres E til Q, gennem reflektoren, som vises med E->Q, som vist ved eksempel på side 7. Bogstavet chifreres nu tilbage gennem rotor 3 og 1, hvorefter den går igennem rotor 2, som illustreres med OPUT, som blev gennemgået på side 6. Til sidst chifreres bogstavet tilbage gennem steckeren, som returnerer et N. På figur 2.7 ses det, hvordan alle bogstaverne er blevet chifreret gennem steckeren, de tre rotorer, reflektoren, tilbage gennem de tre rotorer og til sidst igennem steckeren, hvorefter bogstaverne returneres. De tre bogstaver i parenteser efter denne række, beskriver hvad indikatoren viser, efter der er blevet sendt et bogstav gennem Enigmaen. Hjemmesiderne The Enigma cipher machine [4] og Enigma Applet [1] er blevet brugt som kilder til dette afsnit. 2 der gøres opmærksomt på at bogstavet chifreres fra højre mod venstre, så det er rotor 2 der først bliver aktiveret. 8

17 KAPITEL 2. BESKRIVELSE AF ENIGMA Figur 2.7: Eksempel på chifrering af HELLO ENIGMA 9

18 Kapitel 3 Kravspecifikation Kravspecifikationen er en essentiel del af enhver udviklingsproces. I dette afsnit vil kravene, sat af projektgruppen, blive redegjort for. Kravene vil først blive opsummeret og skrevet i en liste, dernæst uddybes disse. Overordnet krav Ikke-funktionelle krav 1. Skal implementeres i Java. 2. Skal følge Javadoc standarder. 3. Skal være testbart. 4. Konsistent. 5. Genbrugbart. 6. Modulært design. 7. Integrerbart. 8. Ensartet kodedesign. Funktionelle krav 1. Skal have en grafisk brugerflade. 2. Skal have en kommando brugerflade. 3. Skal kunne simulere den virkelige Enigma. 4. De fysiske bestanddele af Enigmaen skal implementeres enkeltvis. 5. Konfigurerbart gennem XML. 10

19 KAPITEL 3. KRAVSPECIFIKATION 6. Importer og eksporter TXT dokumenter. 7. Mulighed for implementation af alfabetet efter brugerens valg. 8. Skal selv kunne lave en tilfældig Enigma opsætning. 9. Skal kunne chifrere en hel streng. 10. Skal kunne indeholde et variabelt antal rotorer. 11. Skal kunne anvende brugerdefinerede rotorer. Uddybning af overordnet krav Ikke-funktionelle krav 1. Enigma programmet skal implementeres i programmeringssproget Java. Argumentationen for valget af Java er, at det er et af projektkravene, at programmeringssproget skal være objektorienteret. Derudover følger gruppen et kursus i objektorienteret programmering, hvor Java er det primære sprog, og derfor har gruppen den samme vidensbasis inden for dette. 2. Koden skal overholde Javadoc-standarder, således kommentarer kan kompileres separat, således de danner en kodedokumentation. 3. Det skal være muligt at foretage Black box og White box testning af programmet. Hvilket kræver at koden skal være veldokumenteret og forståeligt. Testen vil benytte sig af JUnit test. 4. Hvis steckeren, rotoren og reflektoren står ens, på to forskellige maskiner, og den sammen bogstavkombination indtastes på dem begge, skal de give et identisk chifreret output. 5. Det skal ikke være muligt at tilgå kildekoden, men det skal være muligt for andre programmører, at bruge pakkerne i andre programmer. Ved at læse programmets Javadoc kan andre programmører se hvilke funktioner de kan tilgå, og hvordan de fungere. 6. De enkelte moduler skal fungere uafhængigt af hinanden, f.eks. skal stecker og rotor modulerne fungere som individuelle objekter. Gruppen har derfor sat et kriterium at for så vidt muligt undgår at hardcode noget. 7. Kildekoden skal kunne, uden megen redigering, implementeres sammen med andre programmer, f.eks. et chatprogram, klient og lignende, hvor chifrering kan være nødvendigt. 11

20 KAPITEL 3. KRAVSPECIFIKATION 8. Det er vigtig at vores kode design overholder nogle faste regler, for hvad angår ensartethed. Dette vil i sidste ende gøre det mere belejligt for os, og andre at læse og forstå koden. Funktionelle krav 1. Den grafiske brugerflade skal skrives på dansk, selvom koden skrives på engelsk, da programmet hovedsagligt henvender sig til brugere i Danmark, hvorimod koden helst skal forstås af så mange som muligt. Den engelske oversættelse af grafisk brugerflade er graphical user interface, forkortet er det GUI. Gruppen har vedtaget at anvende GUI til at referere til den grafiske brugerflade i den resterende del af rapporten. Der vil være en uddybning af GUI krav på side Kommando brugerflade, er en tekstbaseret brugerflade, der på engelsk hedder commandline interface, der forkortes til CLI. Gruppen har vedtaget at anvende CLI til at referere til kommando brugerflade i den resterende del af rapporten. Der vil være en uddybning af CLI krav på side 13. CLI vil dog kun indeholde de features, der er i en standard Enigma. 3. Programmet skal kunne chifrere på samme vis, som Enigma maskinen anvendt i anden verdenskrig. 4. De fysiske bestanddele af Enigmaen skal implementeres i kildekoden som klasser, der simulerer de fysiske bestanddele. 5. Programmet skal kunne sættes op ud fra et XML dokument. Dette XML dokument skal indeholde informationer om hvordan stecker, rotor og reflektor skal sættes op. Standarden for dette XML dokument vil blive fastsat af vores gruppe. Dette dokument skal kunne eksporteres og importeres. 6. Programmet skal kunne importere et TXT dokument, for chifrering og dechifrering, for derefter at kunne eksportere dokumentet igen. 7. Brugeren skal have mulighed for at anvende et alfabet udviklet efter vedkommendes valg. 8. Programmet skal kunne lave en tilfældig Enigma opsætning, så brugeren ikke behøver bruge tid på at sætte Enigmaen op. 9. Det skal være muligt for brugeren, at vælge om vedkommende vil chifrere enkelte karakterer eller hele strenge. 10. Brugeren skal kunne vælge hvor mange rotorer, der skal være i Enigmaen. 11. Brugeren skal have mulighed for anvendelse af rotorer udviklet efter vedkommendes valg. 12

21 KAPITEL 3. KRAVSPECIFIKATION Uddybning af grafisk brugerflade 1. Overskueligt design - Knapper, menuer, etc. skal placeres efter en ordnet og logisk plan, så GUI fremstår overskuelig for brugeren. 2. Bruger venlig - Det er logisk at bevæge sig rundt i programmet, og benytte alle feature og metoder. 3. Ensartethed - Vinduer og knapper skal være ensartet størrelse. Uddybning af kommando brugerflade 1. CLI skal kunne konfigurer og lave forespørgelser til enigma modulet, så som at chifrere. 2. Ved programkaldet skal man kunne bruge argumenter til at indstille og få hjælp til at bruge programmet. 3. Skulle brugeren ved hjælp af argumenter ved programmet kaldet ikke give nok input, skal CLI spørge om dette. 4. CLI skal kunne skrive en XML konfigurations fil. Dog kun til en standard tysk M3 Enigma maskine. 3.1 kvalitetsmålskema Her er en vurdering af, hvor vigtige følgende kvalitetsmål er i vores projekt: Kvalitetsmål Meget vigtigt Vigtigt Mindre vigtigt Ikke vigtigt Brugbarhed X Integritet/sikkert X Effektivitet X Korrekthed X Troværdighed X Vedligeholdelsesvenlighed X Testbarhed X Fleksibilitet X Genbrugbarhed X Flytbarhed X Interopererbarhed X Tabel 3.1: Kvalitetsmål Vi vil nu begrunde, hvorfor vi har valgt vores prioritering, som vi har. Brugbarhed - Vi fokuserer ikke så kraftigt på brugbarhed, da det er ligetil at bruge en Enigma maskine. Det besværlige er at forstå, hvordan den virker, og dette er ikke nødvendigt for brugeren. 13

22 KAPITEL 3. KRAVSPECIFIKATION Integritet/sikkert - Vi har valgt, at datasikkerheden er uvigtig her, fordi enigma chifferet er helt åbent for alle. Det vigtigste ved et hvert chiffer er, at nøglen er skjult og den er lagret i XML filen, som vi går ud fra bliver transmitteret på en sikker måde. Effektivitet - Vi vil altid prioritere processorkraft frem for ram. Vi forsøger at opnå konstant søgetid i de dele af koden, der tillader det. Dette gøres på bekostning af at bruge mere ram. Dette er både for at gøre programmet mere brugervenligt med lavere svartider, og fordi en personlig computer nu om stunder, har relativt store hukommelseslagre. Korrekthed - For at kunne bruge en chifrerings algoritme, er det vigtigt, at resultaterne er til at stole på. Der sørger for, at implementationen er korrekt ved at teste den så grundigt som muligt. Troværdighed - At den same opstilling altid returnerer det samme output ved samme input. Vedligeholdelsesvenlighed - Vores kravspecifikation er statiske, så når disse er opfyldt, er det ikke nødvendigt at ændre i koden. Testbarhed - At der kan køres automatiske tests. Fleksibilitet - Er ikke så vigtigt, da vi som tidligere nævnt ikke skal ændre i vores system, når det først opfylder vores krav. Genbrugbarhed - At alle klasser skal kunne virke uafhængigt. Flytbarhed - Vi behøver ikke at være opmærksomme på, at vores kode skal være flytbart til andre platforme, da vi koder i Java er dette automatisk muligt. Interopererbarhed - Eksplicit defineret hvilke inputs programmet skal have, og hvilke outputs det returnerer. Skal kunne implementeres I andre programmer. 14

23 Kapitel 4 Udviklingsmodeller I følgende kapitel beskrives, hvordan de enkelte udviklingsmodeller anvendes, og hvilke fordele og ulemper der er ved disse modeller. I slutningen af dette kapitel, vil den udviklingsmodel vi finder bedst passende til projektet, blive udvalgt. Bogen Software Engineering [3] er brugt til alle udviklingsmodellerne. 4.1 Vandfaldsmodellen Vandfaldsmodellen blev introduceret for første gang i 1970erne. I hovedtræk opdeler metoden softwareudviklingen i faser. I den oprindelige model skal hver fase færdiggøres og dokumenteres, inden næste fase kan påbegyndes. På den måde overskueliggøres softwareprocessen, og det bliver dermed lettere at forudsige, hvor lang tid det resterende projekt vil tage. En af de største fordele ved anvendelsen af vandfaldsmodellen er, muligheden for en stram projektstyring, idet hver eneste fase skal grundigt dokumenteres. Ud fra dokumentationen af faserne, er det muligt, at vurdere om projektet halter eller overholder den planlagte tidsplan. Dokumentationen er med til at forbedre strukturen af projektet. Samtidig giver det et godt afkast til en rapport over projektforløbet. Her følger en kort beskrivelse af de forskellige faser. Krav specifikation: Fasen hvor projektets formål fastlægges dvs. hvilket problem der skal løses og hvilke mål der er gældende for projektet. Her igennem udvikles nogle specifikke krav, som alle dele af slutproduktet skal leve op til. System og software design: Fasen hvor systemarkitekturen bliver designet. Designet involverer identifikation og beskrivelse af de fundamentale abstraktioner og deres sammenhæng. Implementation og test: Fasen hvor designet bliver implementeret som 15

24 KAPITEL 4. UDVIKLINGSMODELLER Figur 4.1: Vandfaldsmodellen programkode, og hvorefter de enkelte enheder bliver testet og sammenholdt med kravspecifikationen. Integration og systemtest: Fasen hvor de enkelte enheder bliver testet som et samlet system, for at sikre optimal funktionalitet. Derefter bliver produktet leveret til slutbrugeren. Drift og vedligeholdelse: Fasen hvor systemet bliver installeret og anvendt i praksis. Uforudsete fejl og mangler bliver noteret og rettet. Dette er ofte den længste fase af vandfaldsmodellen. Fordele: Megen dokumentation Fast struktur Let at planlægge og overskue Ulemper: Fast struktur Ingen indbygget kunderinteraktion efter kravspecifikation Der er blevet redegjort for fordele ved denne model, men for overhovedet at kunne anvende modellen, skal kravene fra brugeren være præcist og utvetydigt defineret. Er dette ikke opfyldt, vil det ikke være muligt at udvikle et program, som tilfredsstiller alle involverede parter. 16

25 KAPITEL 4. UDVIKLINGSMODELLER 4.2 Evolutionær model Den evolutionære model eller prototyping, som det også kaldes, er en konstant udvikling og forbedring af prototyper indtil en endelig acceptabel version nås. Den evolutionære model er udviklet ud fra erfaringer hentet fra vandfaldsmodellen. Modellen fungerer dynamisk, dvs. det med lethed er muligt at modificere programkravene, uafhængig af hvilken udviklingsfase programmet undergår. Programmøren følger overordnet denne model 4.2. Figur 4.2: Evolutionær model I begyndelsen formuleres et sæt krav for programmet, herudfra udvikles en initial version, også kaldet en prototype. Denne testes, og uforudsete problemer noteres, og herefter introduceres prototypen for slutbrugeren. Derefter kommer slutbrugeren med feedback, i form af kravændringer og muligvis nogle yderligere krav. Med udgangspunkt i de nye krav udvikles en ny version. Denne version er dels baseret på noget af den gamle kode og dels noget nyt, dette er en intermediet version. Herefter gentages processen. Dette forløb stopper først, når en version nås, som både kunden og udvikleren er tilfredse med. En af de største fordele ved evolutionær programmering er uden tvivl muligheden for at opsnappe uforudsete problemer og herunder den sideløbende udvikling af kravspecifikation, i tæt samarbejde med slutbrugeren. Fordele: Dynamisk Let for slutbrugeren at komme med input Det er muligt at påbegynde programmeringen uden at kende til alle kravene Dette kan dog også betragtes som en af de største svagheder. Brugeren kan konstant komme med ideer til forandring og forbedring af programmet, hvilket kan medvirke til at presse deadlinen, og gøre projektet uoverskueligt for 17

26 KAPITEL 4. UDVIKLINGSMODELLER udviklerne. Der er nogle elementære svagheder i den evolutionære programudviklingsmodel. Ulemper: Manglende gennemskuelighed under projektudviklingen Kun lidt dokumentation imellem faserne Det færdige program er ofte dårligt struktureret Den evolutionære programudviklingsmodel anvendes først og fremmest til udviklingen af små, mellemstore programmer og grafiske brugerflader. Hvis programmet bliver for stort, vil problemerne blive for voldsomme, og det bliver umuligt at holde styr på alle faser af programmeringen. 4.3 Fjerde Generations Teknikker Vandfaldsmodellen og den evolutionære model har begge deres fordele, men som redegjort for tidligere i afsnit 4.1 og 4.2, har de også nogle svagheder. Ud fra nogle af de erfaringer udviklere har gjort sig med henhold til programmeringsfasen i disse udviklingsmodeller, udviklede de fjerde generations sprog. I dette afsnit redegøres for mulighederne ved anvendelse af disse. Figur 4.3: Overordnet model for fjerde generations udviklingsmodeller Udviklingsmodeller ved anvendelse af fjerde generations sprog består hovedsagligt af tre faser: En kravsspecifikationsfase, en programmeringsfase og en testfase. På figur 4.3 ses de tre faser. Kravene specificeres grundigt, og derefter udvikles koden. Til forskel fra de typiske sprog, udvikles koden ikke 18

27 KAPITEL 4. UDVIKLINGSMODELLER af programmører, men derimod genereres den automatisk ud fra kravspecifikationen. Dette sker normalt gennem en grafisk brugerflade, som derefter oversætter kravspecifikationen til kode. Fordelene ved anvendelse af fjerde generations udviklingsmodeller er at ændringer i kravspecifikationen automatisk medføre ændringer i koden. I andre udviklingsmodeller kan uforudsete hindringer, give store problemer for videreudviklingen af programmet. I værste fald kan disse betyde, at det er nødvendigt at begynde helt forfra. Fjerde generations udviklingsmodeller giver udviklerne mulighed for lige meget, hvor langt de er i forløbet at gå tilbage og ændre i kravspecifikationen, som det ses på figur 4.3. Denne frihed kan ikke opnås i nogen af de andre beskrevne udviklingsmodeller. Fordele: Uddybende kravspecifikation. Modellen giver en god forståelse af projekt udkastet i første omgang. Transformationen fra kravspecifikationer til koden er automatiseret. Kravspecifikationen kan optimeres for at få en bedre udførelse af selve programmet. Der forekommer dog nogle problemer, som begrænser mulighederne for denne model. Et af de største problemer er, at hvis muligheden for konstant at vende tilbage og redigere i kravspecifikationen udnyttes, kan strukturen i både kravspecifikationen og koden blive svag. En anden ulempe er, at den automatiske generede kode ikke altid er forståelig. Derfor kan optimering og vedligeholdelse af programmerne blive et stort problem. Derfor er denne model ikke anvendelig i udviklingen af store programmer. Ulemper: Den gentagende revidering af kravspecifikationen kan gøre strukturen meget svag. Koden som bliver genereret er ikke altid let læselig. Det kan være problematisk at optimere og vedligeholde. Modellen er meget anvendeligt til udvikling små applikationer og er ikke nær så praktisk til større programmer, som f.eks. det der skal udvikles i dette semester. 4.4 Spiral Model Spiral modellen er skabt ud fra erfaringer, og er et kompromis af andre udviklingsmodeller, der udnytter fordelene fra de andre modeller. I spiralmodellen 19

28 KAPITEL 4. UDVIKLINGSMODELLER udvikles prototyper, meget lig den evolutionære model, men spiralmodellen har også faser indbygget. Dette gør at den til dels også er dokumentbaseret som vandfaldsmodellen. En anden feature er, at denne udviklingsmodel tillader anvendelse af forskellige modeller til udvikling af koden. Figur 4.4: Spiral model Figur 4.4 illustrerer udviklingsfaserne ved anvendelse af spiralmodellen. Hver omgang i spiralmodellen indeholder fire faser: Kravspecifikation, design, kodning og evaluering. Efter hver omgang undersøges nødvendigheden af endnu en omgang i spiralmodellen. Hvis konklusion af evalueringen er, at endnu en runde er nødvendig, foretages en risikoanalyse. Derefter vælges en udviklingsmodel, der bedst lever op til kravspecifikationen, og denne anvendes under kodningsfasen. Spiralmodellen bygger på andre modellers fordele. Den arver f.eks. fra vandfaldsmodellen, med generering af dokumentation, men undgår en af vandfaldsmodellens største ulemper, nemlig den meget faste fase struktur. Derudover har udvikleren den fordel, at der laves periodiske reviews af kravene til projektet. Dette er med til at gøre spiralmodellen mere fleksibel. Ved anvendelse af spiralmodellen, er det ikke muligt at overskue hele udviklingsforløbet fra start til slut. Derfor er evalueringen sidst i forløbet essentiel. B Bliver denne ikke udført tilfredsstillinde, kan projektet blive forsinket. Fordele: Meget fleksibel Bedre feedback end f.eks. vandfalds modellen Mere dokumentbaseret end f.eks. den evolutionær model 20

29 KAPITEL 4. UDVIKLINGSMODELLER Ulemper: Manglende overblik over hele udviklingsperioden Spiral modellen findes i mange udformninger, med alt fra tre til seks inddelinger eller underfaser. Men fælles er hvorledes cyklusen indledes, og hvordan den afsluttes. Spiralmodellen mangler overblik over hele projektforløbet, og det kan skabe tidsproblemer i slutningen af dette. 4.5 Valg af udviklingsmodel Der er blevet redegjort for flere forskellige udviklingsmodeller, hver med deres fordele og ulemper. Et af kravene til dette semester er, at programmet implementeres i et objektorienteret sprog. Derfor er fjerde generations teknikker ikke anvendelige her. Evolutionær- og spiralmodeller kræver begge en stram projektstyring, og de udvikler begge prototyper. Dette er en fordel, hvis kravene ikke er specifikke. Vores kravspecifikation er fastsat fra anden side ved projektets begyndelse, da Enigma maskinen er fuldt defineret. Derfor vil en udviklingsmodel, som generer megen dokumentation, og hvor der ikke behøves at være så stram en projektstyring, være praktisk. Med dette i tankerne er valget faldet på Vandfaldsmodellen. 21

30 Kapitel 5 Design Dette afsnit vil beskrive designet af vores program, og de forskellige moduler, som vil blive programmeret til vores samlede produkt. Først beskrives selve opdelingen af programmet i moduler. Dette gøres for at opfylder kravet om at vores program skal være modulært, se afsnit 3. Figur 5.1 viser hvordan programmet er delt op. De tre dele er: Enigma modulet Graphical User Interface (GUI) Command Line Interface (CLI) Figur 5.1: Overordent design af vores program Denne opdeling gør det muligt at bruge hvilken som helst brugerflade til Enigma. Fordi det er muligt at udskifte en eller flere af brugerfladerne, uden at skulle ændre i de andre moduler. Til hvert modul er der et tilhørende UML diagram. Klasserne er repræsenteret ved firkantede kasser, som indeholder klassens navn, variabler og metoder. Hvis klassens navn er kursivt, så er der tale om en abstrakt klasse. Efter variabelnavnet er der angivet, hvilken type den repræsenterer. Efter 22

31 KAPITEL 5. DESIGN metodenavnet er der angivet, hvilken type metoden returnerer. Foran variabelnavne og metoderne er der angivet -, + eller #. Et - betyder at, det er en private variabel eller metode, hvorimod et + betyder at, det er public. Et # betyder, at det er en friendly variabel eller metode. 5.1 Enigma Dette modul skal fungere på samme måde som en Enigma maskine Som input skal den have en opsætning af maskinen dvs. hvilken stecker, reflektor og hvilke rotorer, der bliver brugt. Enigma modulet skal også have det input, som skal chifreres med den valgte opsætning. Modulet skal så returnere den chifrerede streng. Enigma modulets ansvar er, at simulere selve Enigma maskinens interne dele, dermed opfylder den vores krav om at skal kunne simulere Enigma maskinen, se afsnit 3. Modulet har tre slags klasser: De centrale klasser der er ansvarlig for at simulere enigma maskinen, config klasserne hvis ansvar er at hente og skrive konfigurationen fra/til en XML fil. De øvrige klasser er af mere til generelt brug af samtlige moduler. Opdeling i modulets centrale klasser er meget lig den fysiske konstruktion af en Enigma maskine, den er delt op i fem klasser: en styre klasse, kaldet Enigma, der styrer alle de andre komponenter. tre klasser der hver repræsenterer en fysik ting i enigma maskinen rotor, reflektor og stecker, en sidste klasse, der indeholder fælles træk for de fysiske ting i maskinen, denne klasse hedder Components. På figur 5.2 ses et UML diagram af vores Enigma design. Der vil nu redegøres for de enkelte klasser Components Components er en abstrakt klasse, der fungerer som overklasse for Stecker, Reflector og Rotor, Components ansvar er at levere nogle variabler og metoder til sine underklasser. Components indeholder: En friendly variabel cryptoalphabet som er af typen Alphabet, som vil blive gennemgået i afsnit 5.1.9, der indeholder det alfabet som metoden cipher bruger til at chifrere den givne karakter med. En friendly variabel clearalphabet som er af typen Alphabet. Der indeholder alfabetet i den korrekte rækkefølge. En public metode cipher. Metoden tager en karakter som input, og ud fra variablen cryptoalphabet og clearalphabet returnerer den en chifreret karakter. 23

32 KAPITEL 5. DESIGN Figur 5.2: UML diagram af vores Enigma design Stecker Stecker er en klasse, der arver fra den abstrakte klasse Components. Den udbygger ikke klassen med ekstra variabler eller metoder. Dens funktion er, at repræsentere den fysiske stecker i enigma maskinen. 24

33 KAPITEL 5. DESIGN Reflector Reflector er en klasse, der arver fra den abstrakte klasse Components, men den udbygger ikke klassen med ekstra variabler eller metoder. Ud fra et design- og programmeringsmæssigt synspunkt, er der ikke forskel på en stecker og en reflektor Rotor Rotor er en klasse, der arver fra den abstrakte klasse Components og udbygger den med seks variable, seks metoder og overskriver cipher metoden. Dens funktion er at repræsentere den fysiske rotor i Enigma maskinen. De sejs variable og seks metoder er: En private variabel rotationpointer, som er et heltal, fortæller hvor langt vi er henne i alfabetet En private variabel notches, som er et karakter array, indeholder de bogstaver, hvor der befinder sig et notch på rotoren En private variabel reversecryptoalphabet, som er af typen Alphabet, se afsnit 5.1.9, indeholder cryptoalphabetet, som det skal se ud, når rotoren chifrer baglæns En private variabel cipheringforward, som er af typen boolean, indeholder sandt, hvis vi går frem igennem rotoren, og indeholder falsk, går vi baglæns gennem rotoren En private variabel isrotatable, som er af typen boolean, indeholder sandt, hvis rotoren kan roteres, og indeholder falsk, hvis rotoren er i stand til at rotorer En private variabel nring, som er af typen heltal, fortæller hvor langt rotorens kerne er rykket i forhold til rotorringen, se evt. afsnit 2.4 En public metode cipher. Metoden tager en karakter som input, og ud fra cipheringforward vælger den, hvilket cryptoalphabet eller cryptoalphabet der skal bruges til at chifrere. Derefter chifrer og returnerer den en chifreret karakter En public metode atnotch. Metoden tager ingen input, men bruger variablen rotationpointer. Den returnerer sandt, hvis vi befinder os på et notch ellers returnerer den falsk En public metode rotate. Hvis metoden atnotch returnerer sandt, så skal rotoren roteres, hvilket sker ved at variablen rotationpointer tælles en op 25

34 KAPITEL 5. DESIGN En public metode rotateback der roterer rotoren bagud, ved at rotationpointer tælles en ned En private metode rearrangealphabet. Metoden bruges i konstruktøren til at lave reverse cryptoalfabet ud fra cryptoalfabet En public metode isrotatable, der returner værdien i isrotatable En public metode indicator der returner en karakter fra klartekst alfabetet beregnet ud fra rotationpointer og nring Enigma Enigma er selve klassen, der binder de forskellige klasser sammen, så modulet fungerer på samme måde som en Enigma maskine. Konstruktøren til klassen får en streng ind, der indeholder stien til en opsætningsfil. Klassen sender strengen videre til Config, se afsnit 5.1.8, hvor klassen henter sin opsætning fra. Klassen består af fire variabler, to metode og en procedure: En public variabel mode som er af typen heltal, der bliver sat til hvilken type alfabet der er tale om, se afsnit En private variable stecker af typen stecker indeholder steckeren En public variable rotorlist af typen rotorlist indeholder rotoren En private variable reflector af typen reflector indeholder reflektoren En public metode cipher der tager en streng som input, og returnerer den chifrerede streng. Metoden deler strengen op i karakterer og kalder metoden subcipher med enkelte karakter som input En private metode subcipher der tager en karakter som input, og returner den chifreret karakter. Metoden chifrerer ved hjælp af stecker, rotorlist og reflector En public procedure machinerotateback, der rotere hele maskinen bagud Dataminer Dataminer klassen læser opsætningsfilen. Den får filens placering i sit input, der er en streng. Klassen henter alle variabler til Enigma maskinen. Den har ni private statiske variabler, ni public statiske metoder og en procedure. En variabel strplainalpha, der er en streng og indeholder alfabetet. En variabel nplainalphabettype, der er et heltal og indeholder alfabettypen, se evt. afsnit omkring vores XML standard. 26

35 KAPITEL 5. DESIGN En variabel strstecker, der er en streng, og indeholder stecker parrene. En variabel strreflector, der er en streng, og indeholder reflektoren. En variabel strrotors, der er et array af strenge, og indeholder rotorenes chifrerings alfabeter. En variabel strnotch, der er et array af strenge, og indeholder rotorens notches. En variabel nring, der er et array af heltal, og indeholder ring indstillingerne for rotorerne. En variabel npos, der er et array af heltal, og indeholder positionen af rotorerne. En variabel nrotors, der er et heltal, og indeholder antallet af rotorer. En procedure minedata, læser XML konfigurations filen og gemmer dataet i overstående variable En metode getrotors, der returnerer et array af strenge, der indeholder strrotors. En metode getnotches, der returnerer et array af strenge, der indeholder strnotch. En metode getrings, der returnerer et array af heltal, der indeholder nring. En metode getposition, der returnerer et array af heltal, der indeholder npos. En metode getplainalphabet, der returnerer en streng, der indeholder strplainalpha. En metode getplainalphabettype, der returnerer et heltal, der indeholder nplainalphabettype. En metode getreflector, der returnerer en streng, der indeholder strreflector. En metode getstecker, der returnerer en streng, der indeholder str- Stecker. En metode getnumberofrotors, der returnerer et heltal, der indeholder nrotors. 27

36 KAPITEL 5. DESIGN WriteXML WriteXML er en abstrakt klasse, der har ansvaret for at skrive en enigma konfiguration til en XML fil. En public procedure writesetuptoxml tager en ArrayList som input. Den laver en XML fil ud fra listen. Inputtet skal være på formatet som vist på figur 5.3. Alt i ArrayListen er strenge, da det man ikke er muligt at tilføje basale datatype til en ArrayList. Figur 5.3: Diagram over inputet til vores WriteXML Config Config er en klasse, der får input fra et XML dokument ved hjælp af DataMiner klassen, se afsnit I dette XML dokument findes opsætningen til Enigmaen, dvs. hvilken reflektor og stecker, der skal anvendes, samt antallet af rotorer, og hvilke rotorer der skal anvendes. Derved opfyldes vores 28

37 KAPITEL 5. DESIGN tredje funktionelle krav: Konfigurerbart gennem XML. Efter at have læst konfigurationen bygger configklassen alle objekterne til maskinen. Klassen består af fem variabler og to metoder: En friendly variabel stecker indeholder et objekt lavet ud fra klassen Stecker, se afsnit En friendly variabel rotorlist indeholder en række af objekter lavet ud fra klassen Rotor, se afsnit i en ArrayList. En friendly variabel reflector indeholder et objekt lavet ud fra klassen Reflector se afsnit En friendly variabel plainalphabet som er af typen Alphabet, se afsnit 5.1.9, indeholder det alfabet der bruges. Den friendly variabel nplainalphabettype, som er af typen heltal, indeholder typen af alfabetet, se afsnit En private metode cyclicconvert. Metoden kaldes fra konstruktøren og modtager et alfabet som er cyklisk noteret 1. cyclicconvert omarangerer bogstaverne så de i stedet danner et kryptoalfabet Alphabet Alphabet er en abstrakt datatype, der lagre et alfabet. Dette er lavet for at gøre det lettere at chifrer, endvidere opnås der konstant søgetid i alfabetet. Dette er et af vores kvalitetsmål effektivitet, som beskrives i afsnit 3.1. Alphabet er kun i stand til at lave gyldige alfabeter med lige antal karaktere. Alphabet indeholder: Tre private variable, 2 private metoder og 5 public metoder. en private variabel arrayindexes et array af heltal, der starter ved den mindste karakters ASCII værdi, og går op til den største. Dette vil sige, at den første plads 3 er index af den karakter med mindste ASCII værdi, og den fortsætter op til den største ASCII værdi, array lænden er dermed største ASCII værdi minus mindste ASCII værdi. En private variabel arrayalphabet er et array af karakterer, der indeholder selve bogstaverne i alfabetet. 1 Cyklisk notation betyder at en karakter chifrerer til det til venstre for og det sidste i hver tuppel krypterer til det første. Det betyder at (AB) denoterer at A chifrerer til B og B chifrerer til A. I en stecker eller reflector er der kun to bogstaver i hver tuppel 2 Kryptoalfabetet ZBCDEFGHIJKLMNOPQRSTUVWXYA denoterer at A chifrerer til Z og visa versa. Det svarer i cyklisk notation til (AZ) eller (ZA) 3 index nr. 0 29