Enkel textkryptering...

C, C++, Pascal, Assembly, Raspberry, Java, Matlab, Python, BASIC, SQL, PHP, etc.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6889
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Enkel textkryptering...

Inlägg av Marta »

Målet är en enkel textkyptering som är några snäpp starkare än ROT13 och som använder ett keyword. Vore bra om samma algoritm omväxlande gjorde encode/decode.

RC4 är enkel och initieras med keyword. Xor med denna så är det löst, men nej. Chiphertext måste vara fri från CR/LF/TAB/SPACE. Skall även palla att manglas fram och tillbaka ISO8859/UTF8 med enkel algoritm. Första snabba tanken, nolla bit 5 till 7 från RC4 innan xor. Nej, dj**la mellanslag sänker det. Lägg till att substituera dessa med lämpligt tecken ser ut att vara enda sättet, men då måste algoritmen veta indatatyp.

Som gammal trött käring med ett dött hål i hjärnan hittar jag ingen bra lösning utan sidoinformation i någon form. Det känns olösbart, men är det så? Känna igen klartext med ordlista är ingen lösning. Bryta på näst sista tecknet kan vara, men känns obra.

Orsaken till problemet är när en rad ciphertext råkar sluta med mellanslag. Avslutande sådana på en rad rensas bort.
Mr Andersson
Inlägg: 1394
Blev medlem: 29 januari 2011, 21:06:30
Ort: Lapplandet

Re: Enkel textkryptering...

Inlägg av Mr Andersson »

base64-koda RC4-resultatet?
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Enkel textkryptering...

Inlägg av xxargs »

finns typ 14 varianter av Base64.

Skall man ha URL/filnamnsäker kodning så föreslås numera "modified Base64 for URL"

Det som skiljer mellan de olika versionerna är tecken 62 och tecken 63, hur paddingen hanteras, ev. CR+LF-hanteringen och om checksumma skall ingå

tänk på att när man kör base64 så ökar filstorleken med typ 1.33 gånger då det egentligen kan betraktas som en kanalkodning för en transportkanal med en viss karakteristik
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45175
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Enkel textkryptering...

Inlägg av TomasL »

Chiphertext måste vara fri från CR/LF/TAB/SPACE
Förstår inte riktigt vad du menar?

Varför funkar inte vanlig typ av kryptering?
Användarvisningsbild
4kTRB
Inlägg: 18289
Blev medlem: 16 augusti 2009, 19:04:48

Re: Enkel textkryptering...

Inlägg av 4kTRB »

Caesarchiffer kanske kan vara något även om jag inte vet om det uppfyller just dina speciella krav.
https://sv.wikipedia.org/wiki/Caesarchiffer

Jag har faktiskt läst en högskolekurs i krypteringsteknik,
boken tror jag finns som pdf, tar upp många kul chiffer.

Bild
guckrum
Inlägg: 1671
Blev medlem: 19 juni 2012, 09:04:27
Ort: Lund

Re: Enkel textkryptering...

Inlägg av guckrum »

Vad är så att säga problemet, och vad menar du med enkel? Håller annars med xxargs, separera "transport" från "kryptering" och lös dessa var för sig.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45175
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Enkel textkryptering...

Inlägg av TomasL »

XTEA är väl det absolut enklaste varianten, vilken ger mycket hög säkerhet.
E Kafeman
Inlägg: 3238
Blev medlem: 29 april 2012, 18:06:22

Re: Enkel textkryptering...

Inlägg av E Kafeman »

Jag har en hemkokt text-kryptering. Hemkokta krypton brukar sällan hålla för närmare analys men det beror också på hurdant behovet ser ut.

Grundtanken är att den krypterade strängen inte ska innehålla redundans eller vara förutsägbar hur en text kommer se ut i sin krypterade form eller ha en viss krypterade sträng-längd.
Strängen "Hemlig text med hemligt krypto" kan som krypterad motsvar strängen "Eo+╫ε:+ôtφ`£t≤`rt{`∞╧╚`" eller "⌠∩5X±∩⌐Xσ$÷" eller i princip oändligt antal andra varianter utan att man behöver ändra nyckeln.

Krypterade texten ska vid dekryptering föregås av en krypterad text-sträng som vid varje de-kryptering hämtas lokalt eller externt i sin krypterade form.
Både den hämtade och egna texten är då krypterade och bägge ser ut som random hex-tecken.

Bägge strängarna sammanfogas efter varandra till en lång binär sträng.
Sedan börjar man beta av. De två första bitarna läses och avtolkas som ett antal alternativa instruktioner:
00= läs nästa 2-7 bitar tills två nollor i följd läses, hämta 8-bitar av den krypterade bit-strängen så många bytes som dessa bitar anger tillbaka i strängen och läs nästa 8 tecken och exora dessa tal med varandra för att få fram klartext ASCII-tecken.
01=läs numeriska värdet av nästa 5 bitar som ett hopp tillbaka i redan avkrypterad text, och hämta den bokstaven.
10=nästa två bitar är räknevärde 1-5 som anger stränglängd. Hämta ytterligare 7 bitar för hur långt tillbaka text med denna stränglängd ska hämtas.
11=Tolka all fortsatt binär-data baklänges tills nästa instruktion 11.

Även väldigt repetitiv text kommer se ut som random hex-tal. Ett tecken kan ha många olika längder som vid kodning kan väljas
Kodningsfallen 00 och 11 ger vid kodningen valbar längd. 1111 är t.ex. möjlig instruktion.
00 kan ges valbart total längd 14 till 19 tecken vid krypteringen.
01 och 10 minskar redundansen.

Dekryptering är mycket enkel om man har nyckeln.
Även om man helt förstår kryptometoden är det mycket svårforcerat utan initiala strängen, då det inte finns något repetitivt i binär-massan att greppa för blind-försök till avkodnig.
Krypterade texten är som till en regel betydligt kortare än okrypterade texten.
Det finns ingen bokstav för bokstav-kryptering.
Även om okrypterade textens innehåll är repetitivt ser inte krypterade varianten på något sätt regelbunden ut.
Samma krypteringsmetod som upprepas kommer skapa två olika binära stränga med random bitar och random längd även om nyckeln är densamma.

Det är lätt att skapa den krypterade strängen.
Att söka strängar bakåt är samma som vid enkel RLE (RunLengthEncoding).
Man söker bakåt rekursivt i egna okrypterade texten hur långt bak och hur många bokstäver vid denna punkt är desamma.

Just att eleminera repetiviteten i krypterade strängen och att längden inte speglar exakta text-längden gör försök till brute force eller dictionary-attacker meningslösa.
Vid kodningen kan man random välja metod 00-11 vilket ger helt olika binära ut-massor även om dekrypteringen resulterar i samma text.
Det går inte utläsa bokstavsfrekvens eller liknande.

Det är lätt att skapa varianter på denna kodning.
Har man satt max pekar-längd tillbaka i RLE till 128 tkn bör nyckel-texten var minst så lång.
Jag har kört med varianter typ om pekaren är större än 64 hopp ska ytterligare 5 bitar läsas för att skapa ett tal 1-256+64. Om detta nya talet är över 128->fortsätt rekursivt. På det viset kan man peka valfritt långt tillbaka även i stora textmassor.
Det blir då nära bok-krypto men med variabel krypto-längd per tecken.

En enkel variant av detta krypto kördes på en sida ur en gammaldags telefonkatalog.
Det blev av naturliga skäl en väldigt kort krypterad sträng, den var kortare än 15% av original-text.
Frekvensanalys av hex-talen gav ingen mätbar tyngdpunkt.

Det är inte något super-krypto baserat på stora primtal och liknande men är väldigt resurssnålt vad gäller CPU-last och CPU-tid och relativt okomplicerad avkodning som i princip behöver tre if-satser, Fjärde alternativet, 11, är "then shift inverse flag".
I min egna variant har jag inte exakt dess IF-satser men något relativt likt.
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Enkel textkryptering...

Inlägg av xxargs »

vad är det för ambitionsnivå på krypteringen - det enkla låset som petas enkelt upp på dagboken eller högsäkerhets bankvalv ???


---

Kan inte bedöma E Kafemans förslag - men eftersom den reducerar meddelandets längd så har den komprimerande egenskaper och det är tveksamt om en komprimerande algoritm - låt vara med självpermuterade algoritm - kan anses som kryptografiskt starkt...

Nästan alla hem-hopkok av krypto oavsett sort har mer eller mindre fatala svagheter som gör dessa lätta att knäckas när man väl letat, analyserat och hittar dess svaghet - i de flesta fallen så är inte attackstyrkan av dessa heller enkelt mätbar (och är problematisk även på erkänt genomanalyserade officiella algoritmer) och i kryptosammanhang så vill man gärna ha en beräkningsbar attackstyrka mha. nyckellängder etc.

TomasL skrev:XTEA är väl det absolut enklaste varianten, vilken ger mycket hög säkerhet.
XTEA har sina problem - det finns en XXTEA för att lappa svagheter i XTEA som i sin tur var en lappning av svagheter i TEA...

Men grundproblemet som gör dem icke aktuell idag i mer seriösare sammanhang är att den är för liten med bara 64 bit block-storlek, vilket innebär att man riskerar krock med 50% sannolikhet (och därmed informationsläckage av nyckeln) redan efter 32 GB datamängd pga. fördelsdags-paradoxen även om cipher i sig skulle vara helt felfri.

Det är därför som dagens AES har 128 bitars blockstorlek för att mota just den delen (i förslagen fanns också 192 och 256-bits alternativ och vidare men togs inte med i standarden... NSA bakom detta ???)

---

Men de stora misstagen görs inte på vald cipher och dess eventuella styrka - utan hur man hantera när datamängden är större än en block (i XTEA fall 64 bit eller 8 Byte) - hur göra med nästa block, hur gör man i slutändan när sista blocket inte är helt utfylld, att tex. fylla dessa sista positioner med '0' ger en känd attackvektor som används flitigt vid många angrepp.

NTLM för SMB v1 har en sådan situation då man använde DES med 56-bitar blockstorlek och om passordet var 8 tecken så behövde man bara prova igenom alla alternativ med 'brute force' för det första 7 tecknen (vilket går inom timmar, idag kanske bunt antal minuter för samtliga alternativ) och bara prova alfabetet på första tecknet i den 8:e tecknet eftersom resten var just och känt '0' - då passordet kunde betraktas som uppdelade separata 7 tkn ord utan beroende av varandra - hade 8 tkn ingått/beroende med dom första 7 så hade attacksvårigheten ökat med en faktor 95 gånger om hela alfabetet användes och valts helt slumpmässigt (vilket inte heller gällde NTLM v1 eftersom NTLM v1 bara använde stora tecken + symboler och de små tecknen omvandlades till stora tecken innan krypteringen, vilket bara gav 68 teckens omfång). Därav rekommendationerna har varit minst 15 tecken lång passord i windows i många år då över 14 tkn så valdes annan och säkrare algoritm. Hur många använder 15 helt slumpmässiga tecken för sin dagliga inloggning i sin win-burk - ja dom är lätt räknade... hur många använder mer 12 tecken - ja dom är också relativt lätt räknade...

Det är i princip först i och med WIN10 man gjort sig av med 'lasset' iom. man spärrar defaultmässigt för SMB v1 som nätverksprotokoll då hacken företrädesvis har gjorts över nätverk och där NTLM v1:s passordshantering har varit den svagaste delen...

Kort sagt passordet var lagrat som i ECB-mode och den mode skall man undvika till varje pris såvida man inte har ett nytt 16-byte passord för varje 8 byte-block.

verkan av ECB-mode av kryptering på större filer kan man se https://en.wikipedia.org/wiki/Block_cip ... ration#ECB (skrolla ned en bit och titta på bilderna) och är rätt avslöjande.

Ett rätt berömt misstag är gjord i 'bcrypt' (och i BSD och linux-världen dödad som applikation och kan bara avkryptera gamla redan gjorda bcrypt-arkiv/filer) där verkan av ECB-mode länge var dolt och oupptäckt i och med bcrypt använde komprimeringen av texten innan kryptering defaultmässigt - och komprimering anses inte tillföra någon som helst kryptografisk styrka.

Även krypterande filsystem som encFS är satt under karantän/ej rekommendabelt då dess hantering av slutet av filerna och det inte går upp jämt rent blockmässigt, är ifrågasatt och många tror och är rädda för att detta kan användas som attack-vektor.

Vidare läsning (av många) är https://stackoverflow.com/questions/122 ... tr-ocb-cfb
E Kafeman
Inlägg: 3238
Blev medlem: 29 april 2012, 18:06:22

Re: Enkel textkryptering...

Inlägg av E Kafeman »

Just detta att minska överförd informations redundans är bland det viktigaste man kan göra för att bibehålla krypterings-höjd oavsett tids eller eller datorer beräknings-aspekt, då det försvårar möjligheten till reversering mha superdator-resurser. Det finns inget att greppa i den krypterade massan som leder mer till ett mer dekrypterat resultat än ett annat. Mer beräkningskraft och tid tillför inget.
Jämför RSA-128 där det är möjligt att med matematisk säkerhet bestämma att man lyckas med brute force dekryptering inom viss tid för en given beräkningskraft.
Med redundansfria meddelanden blir även ett Caesar chiffer omöjligt att lösa med brute force.
Problemet är att det inte går nå total redundans men det går komma rätt långt även med välvalda måttligt stora nycklar.

Antag ytterst förenklade krypto-situationen, där man vill hemlighålla korta meddelande från avtolkning, typ radio-utsända eldorder från en stridslednings-central.
Sådan information är av värde bara när den är färsk. Nästa minut kan fienden konstatera att en projektil skickades iväg utan att avtolka något meddelande.
Om man förenklar antalet möjliga eldordrar till de fyra väder-strecken, "Skjut söder", "Skjut väster"... samt sänder dessa eldordrar på radio med typ av kryptering som gör att "skjut söder" alltid ger samma kyptotext får man det problemet som Enigma-krypteringen gav, samt många andra moderna algoritmer. Som fiende behöver man inte dekryptera något alls, det räcker med att känna igen sträng-mönstret som motsvarar söder, norr.. För att minska problemet åtminstone för dag till dag beräknades tyskarna en ny Enigma-nyckel varje dag.
Då fick man ett annat redundans-relaterat problem. Man skickade ut en krypterad väder-rapport varje morgon. Eftersom väderrapporter för dag från dag i okrypterad form till stor del var snarlik så kunde dagens nyckel snabbt reverseras fram även av engelsmännen.

Hög redundans är dels om krypterade meddelandet i sej innehåller repetitiv data, dels om två efterföljande meddelanden med samma okrypterade innehåll också i sin krypterade form är identisk om nyckeln inte byts eller på annat sätt bibehåller ett identifierbart mönster.
Därav att ett meddelande bör såväl inuti meddelandet såväl som vid efterföljande meddelande ha random struktur även om okrypterade innehållet är identiskt i bägge meddelandena och detta utan behov av förnyat nyckel-utbyte, vare sej av öppen eller privat nyckel, då nyckelutbyte i sej alltid är en säkerhetsrisk.

Informationen från en stridslednings-central är som nämnts färskvara. Att evt. krypto kan reverseras på en halvtimme i en superdator är då ointressant.
Om man har en hemlig text och innehållet ska hemlighållas för obehöriga inte bara i kort perspektiv utan även under längre tid, och även låsa ut NSA, är det bara att välja en bra nyckel i mitt hemkokta krypto. Nyckeln behöver inte begränsas till 128 eller 256 bitar för att undvika repetitiva mönster, man kan t.ex. meddela mottagaren av den hemliga texten att nyckeln är 1978060-2000, vilket då sen tidigare är överenskommet att det handlar om 256 tecken av textmassan med startpunkt efter 2000 bokstäver i Dagens Nyheter av det datumet som sedan rullande används som nyckel, dvs en del av nyckeln förbrukas för varje utförd del-kryptering. Så länge inte NSA kan hitta exakta nyckeln ger varje dekrypterings-försök ett fritt random resultat även med miljoners år av superdatorers dekrypterings-resurser. Inte ens kvant-datorer kan lösa problemet.

Ett problem är att graden av reduktion av onödig informations-överföring till stor del beror på nyckelns innehåll.
Om nyckeln är en sida ur telefonkatalogen är det givet att reduktionen blir hög om man vill överföra snarlik typ av information.
Av samma skäl fungerar inte reduktion av åäö första gången de förekommer i en text om nyckel-text är engelsk. Efterföljande åäö fungera bättre, dvs de kan anta ett random värde (inom ett intervall) som krypterad massa.
Det stora problemet är att man alls använder någon form av nyckel. Det finns alltid möjlighet att nycklar kommer på avvägar.

En återkommande diskussion, varför alls lägga massa energi att brute forca, när det antagligen krävs mycket mindre energi att övertyga någon person med full access till ett system att överlämna information och nycklar.

Kvant-kryptering eller information överförd med enskilda fotoner förutspåddes en gång i tiden att lösa detta, ingen nyckel behöver överföras och det går inte avlyssna utan att det märks, men i dag är man inte så säker längre.
Kvantdatorn påstås däremot kunna reverse-beräkna RSA-128 på nolltid, när man väl löst lite praktiska problem...

Att endast skicka data med låg redundans i kombination med att slumpkoda längd och värde gör obehörig dekryptering svår.
Ett av problemen med detta är att det ur programmerings-synpunkt inte är helt lätt att åstadkomma verklig slumptals-generator.
För att åtgärda det så skapades en funktion Dual_EC_DRBG PRNG som skulle skapa kryptografiskt säkra random-tal, vilket skulle göra obehörig dekryptring svår.
Men det visade sej att NSA antagligen lagt in en bakdörr i koden.. https://en.wikipedia.org/wiki/Dual_EC_DRBG

Det finns random-tjänter på nätet men i princip ingen är pålitlig om man är konspiratoriskt lagd.
Helt mjukvarugenererade slumptal har nästan alltid tydliga mönster. En av de som påstås bättre är Blum-Blum-Shub.
Lite bättre hembyggd hårdvaru random generator bygger ofta på termometer eller gamma-detektor.

Frågan är vilken säkerhetsnivå som TS eftersträvar. Denna koden kan vara fullt tillräckligt och jag tror NSA går bet på det.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45175
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Enkel textkryptering...

Inlägg av TomasL »

Frågan är vilken säkerhetsnivå som TS eftersträvar. Denna koden kan vara fullt tillräckligt och jag tror NSA går bet på det.
Inte om de läst Kalle Blomkvist, för det har väl alla, eller :D

När vi krypterade i lumpen, så byttes alla siffror ut mot text, alla mellanslag togs bort samt alla skiljetecken ersattes med text.
Använde vi HAA så var det nya nycklar för varje meddelande, körde vi MGC, så byttes nycklarna varje dag.


Dessutom så var i stort sett vartannat meddelande fejkad textmassa.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 6889
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Re: Enkel textkryptering...

Inlägg av Marta »

Nja, nivån skall ju vara klart högre än dagbokslås som öppnas med knappnål eller lektrams som småttingarna roar sig med.

Den där komprimerande metoden påminner mera om .zip än kryptering. En .zip ser ju ganska obegripligt ut, undrar hur svår den skulle vara för en expert att lösa. Det här beskrivna påminner om zip utan huffmankodning och med password tillagt på något sätt. C-kod kanske finns?

Har en till beskrivning på en annan patentmetod som bygger på primtal, men även det är komplicerat, fast det tror jag mer på.

RC4 är ju beprövad och har granskats väl. Finns vissa svagheter, men det har allting. Största svagheten är nog att pwd kan bli utnött om det används till för många texter. Kodning av endast 5 bits är nog också en svaghet. De höga koderna kan ju förutsäätas vara åäö och med mycket nog material kan fragment av keystream återskapas. Hur långt det räcker för att "synka" RC4 eller dra ut pwd är över min nivå.

Nåväl, det finns de som gillar sådant, vi får se om texten nedan postas som klartext ikväll... RC4 xor med de tre översta bitarna nollade för att undvika kontrolltecken. Sista tkn på raden som det är för att undvika 0x20 i denna position. Enkelt och lätt, dessutom är pwd ganska svagt

Rhl`m=úm7vke
Lhk|x`,í{"`oqv`n
Htpuizo3ùh!egne
]ix#sw||pbzk)|fzfn

Yavt?uur5bvhefr
Aaíbmql!ü(`rt
_{docf4~ef7xbl~zor
U)eñ~lx~)jnf`t

M}nswok>jij$khät{r
Wö5fvv};ibr:cå$e`çdt
Cxo~|xu9`ýtz`r
Bka*z}|vd*ety0udc)iôst

Lá}~qlrep2|se:xévxt
K|ikc$fp}rhw<iszb~<ebrr
Cvqin&ampnx {md(tøzbht
I}c5ar|l7föo/xde2bkr

Fqu{w7÷p<uy{e
\wffub=ëe5biw~wn
Rvaq{oe=ëd+t{brhn
_pn {étfh|1kgqcn
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: Enkel textkryptering...

Inlägg av xxargs »

Sista steget med XOR av meddelandet i RC4 är inte problemet - svagheten - som nästan gäller alla kryptosystem - sitter i administrationen av nycklarna och genereringen av psedolumptalen.

Med en perfekt slumptalssträng som meddelandet XOR:as emot så är det lika oknäckbar som krypton med engångsnycklar med nycklarna minst lika stor som meddelandet.

Nu är det inte så i RC4 då bla. de första byten i psedoslumptalsströmmen läcker för mycket av slumptalsgeneratorns interna lägen (och därmed läcker information om använda nyckeln) och skall man mota denna svaghet så bör man låta den tomgångsköra minst 768 byte innan man börja använda strömmen för kryptering.

En sak till - RC4-meddelande skall aldrig någonsin användas med samma nyckel mer än en enda gång.

Det är nämligen så att om man har ett krypterat meddelande och dess motsvarande klartext i RC4 - så kan man avkoda annan krypterade meddelande gjort med samma nyckel genom att använda krypteradtext1 EXOR klartext1 EXOR krypteradtext2 = klartext2 utan att känna till nyckeln - dock inte längre än vad klartext1 sträcker sig i antal tecken.


Det är naturen med användningen av EXOR som gör att man kan göra på det sättet och annan tillämpning på samma sätt är i tex. RAID5 när man återskapa informationen i den utbytta disken av redundansen/pariteten av de andra diskarnas datainnehåll med samma teknik med EXOR.

Därför bör man med RC4 ha en 'nonsens', salt, löpnummer eller annat, som kan vara publikt (i tex i filnamnet) förutom lösenordet i sig som hålls hemlig i lösenords-strängen så att lösenordssträngen hela tiden modifieras något för varje ny kryptering och ny meddelande.

RC4 har andra 'issue' som att tex. kunna bit-flippas på den krypterade delen utan att det märks under uppackning (medans det blir knas på allt efterkommande om tecken saknas och man får prova positioner tills det är synk igen), medans i andra krypteringssystem så kan hela meddelandet efter bit-felet bli nonsens och obegripligt - ibland är det önskvärt - ibland inte som tex. i praktiska fall med osäker och störd förbindelse eller mänskliga misstag gör att tecken förväxlas till något annat eller helt förloras under vägen.

Med andra ord i filen som överförs kanske man skall ha checksumma med jämna intervall som verifierar textstycket integritet och är det viktigt att meddelandet kommer fram utan att sändas om (då med annan nyckel i så fall) - bygga in felrättning (FEC)...

Att (FI) sände om samma meddelande mer än en gång med samma nyckel men med olika fel och misstag på olika ställen i överföringen, att delar av meddelandet var känt som standard-formulering, hälsningsfraser mm mm. , räckte som angreppsväg in för att kunna knäcka meddelande under WW2...
Användarvisningsbild
Krille Krokodil
Inlägg: 4062
Blev medlem: 9 december 2005, 22:33:11
Ort: Helsingborg

Re: Enkel textkryptering...

Inlägg av Krille Krokodil »

TomasL skrev:
Dessutom så var i stort sett vartannat meddelande fejkad textmassa.
Något bättre kryptodisciplin än tyska marinen där vartannat meddelande var sjöväderraport inbäddat mellan ständigt återkommande floskler typ "Oh helgad vare vår store führer!" och "Heil Hitler!". Tack så hjärtligt sa man på Bletchley Park...
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45175
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Enkel textkryptering...

Inlägg av TomasL »

Ja, det lär ju totalt förstöra möjligheterna för eventuell de-kryptering.
Skriv svar