Zelfgemaakte encryptie. Hoe te testen?

[Onbekend]

Ik heb in de afgelopen weken wat meer over encryptie gelezen en ben zelf maar wat gaan programmeren en experimenteren. Nu heb ik dus uiteindelijk een programma waarmee ik een bestand kan encrypten en weer kan decrypten. Op zich allemaal leuk en aardig natuurlijk, maar ik wil nu eigenlijk ook de "kwaliteit" van de encryptie testen.

Als ik de encrypted file in een grafiekje zet, lijken het random waardes. Ik kan er in ieder geval geen patroon in ontdekken. Verder, als ik maar 1 letter van het wachtwoord verander of het wachtwoord langer/korter maak, komt er een totaal andere encrypted file uit.

Maar hoe bepaal ik bijvoorbeeld hoe lang het brute forcen duurt? Ik vind het namelijk vrij complex om dat uit te rekenen. (Er zitten alleen maar shift- en xor-bewerkingen in.)
Hoe weet ik dat ze aan de hand van de geëcrypte data niet het wachtwoord kunnen achterhalen?


Met zoeken kom ik niet verder. Ik ben wel gestuit op dit topic: [Decryptie uitdaging] Kraak mijn encryptie maar daar haal ik ook niet zoveel informatie uit. Verder zoeken (op Google) kom je alleen maar uit op pagina's met uitleg over technieken van encryptie en opslagfabrikanten die encryptie aanbieden. Over het geavanceerder testen van de encryptie zelf is niet zoveel over te vinden....

[Nvidiot]

Wikipedia: Cryptanalysis is een aardig startpunt hiervoor.

Verder als opmerking: er zijn veel mensen die dit soort dingen proberen en het lukt maar zeer weinigen om zelf een encryptie methode volkomen foutloos te bedenken en implementeren. 1 Klein foutje is al desastreus voor je encryptie methode/implementatie.

[Onbekend]

Ik zie nu pas dat de Engelse versie van die pagina veel meer informatie bevat dan de Nederlandse versie.
Met de meeste informatie wat daar in staat heb ik al rekening mee gehouden.


De encryptie van mij is niet zo complex, waardoor fouten niet zo moelijk te vinden waren. Ik heb flink veel getest met verschillende typen files. Ik heb zelfs zip-files van 500 MB geëncrypt en gedecrypt, en ik kon alle bestanden foutloos uitpakken. Bij een paar bestanden heb ik getest of ze ook nog te openen waren, en dat ging goed. Als ik een foutje heb in de encryptie verwacht ik dat de zip-file niet foutloos uit te pakken was.

Het kan overigens best zijn dat de encryptie die ik heb bedacht al bestaat of bijna het zelfde is. Er zijn zoveel verschillende soorten, maar allemaal is het net ietsje anders.

[TerminalNL]

Probeer ook eens iso files, iso heeft sneller last van als die een paar bitjes mist.
Bij zip-files zit er nog behoorlijk deel extra bitjes bij

[Dutch_Razor]

Ik denk dat je t beste kan testen door een sfv van een file te maken, die file te encrypten, dan decrypten daarna weer de sfv file eroverheen (om te kijken of t werkt iig).

[MSalters]

In cryptanalysis ga je er meestal van uit dat het algoritme publiek is, dus dat kun je hier (of in P&W) wel neerzetten. Zo blind zeggen of iets veilig is lijkt me ongepast. "Alleen shift en XOR" zou behoorlijk goed kunnen zijn. Meestal niet, want die shifts en XOR's moet je erg zorgvuldig kiezen om cryptanalysis te hinderen. En als jij niet weet hoe het moet, dan heb je een grote kans dat er iets fout gaat. Wat is bivoorbeeld de relatie tussen het aantal 1-bits in je input en je output?

[CyBeR]

Onbekend schreef op zaterdag 15 maart 2008 @ 23:21:
Als ik een foutje heb in de encryptie verwacht ik dat de zip-file niet foutloos uit te pakken was.

Da's een ander soort fout. Nvidiot bedoelt een fundamentele fout waardoor je minder key mogelijkheden hoeft te doorzoeken bij een exhaustive search. Bijvoorbeeld: als bit 26 van de output 1 is, is bit 4 van de key dat ook altijd. Dat soort ideeën.

[Onbekend]

@Ricardo:
Ik heb het ook met een ISO-file getest en het bestand kon ik gewoon openen. Verder heb ik er niets mee gedaan. Ook de MD5 checksums van beide files zijn identiek.

---

@MSAlters:
Ik heb als voorbeeldfile dit genomen: http://www.starfix.nl/getfile/everest_home.exe
Dit bestand heeft
16663937 enen en.
16770407 nullen.

Het geëcrypte bestand heeft
16717707 enen en
16716637 nullen.

Met een iets ander wachtwoord heeft het bestand
16717513 enen en
16716831 nullen.

Het aantal nullen en enen zal volgens mij nooit gelijk worden omdat de bestandsdata zelf niet random is.

---

@CyBeR:
Ik heb zoiets nog niet direct gevonden dat het ene bitje een direct verband heeft met een ander bitje.
Alles is afhankelijk van elkaar.

---

Hier is mijn beschrijving van het encrypten of encoderen. Ik ben verder niet verantwoordelijk voor de gevolgen en/of het gebruik hiervan.


Het encrypten of encoderen gaat bij mij in 3 stappen.

Eerst de voorbereiding:
- Eerst moeten we het wachtwoord vertalen naar een array van complete bytes.
- En we hebben een seed-file nodig. Deze file is altijd 256 bytes groot en bevat alle mogelijke bytes, maar dan willekeurig door elkaar heen.

Stap 1: Xor van het bestand de bytes met de volgende bytes. Dit doen we steeds tot en met het einde van de file.

0x12 0xE7 0x78 0x9C <-- voorbeelddata
0xE7 0x78 0x9C 0x00 <-- Data, maar dan een byte naar links verschoven.
---------------------------------------- XOR
0xF5 0x9F 0xE4 0x9C <-- Resultaat

Stap 2: We voegen de seed-file toe. Afhankelijk van het wachtwoord wordt de beginpositie in deze file bepaald. Met deze bytes van deze file wordt met de bytes van de file weer een xor-bewerking uitgevoerd. Als het einde van de seed-file is bereikt, begint hij weer van voor af aan.

Stap 3: We voegen de bytes van het wachtwoord toe. Dit gaat op de zelfde manier als stap 2, maar dan is de beginpositie gewoon positie 0.


Het decoderen gaat in de omgekeerde volgorde natuurlijk

Ik heb voor de 3 stappen gekozen omdat je zonder stap 1 heel gemakkelijk het beginstuk van de file kan zien. Als het met "BM" begint, weet je al snel dat het om een bitmap gaat natuurlijk, en kan je de volgende bytes wel ongeveer raden.

De stap 2 is dus om "willekeurige" data te krijgen. zonder stap 2 zou het wachtwoord "Test1" en "Test2" maar kleine verschillen opleveren. Omdat ik de beginpositie van het wachtwoord af laat hangen, geeft een klein verschil in het wachtwoord al een grote verandering.

En de derde stap is het wachtwoord er in te zetten, en dat is natuurlijk altijd nodig. Ik heb het maar simpel gehouden door er alleen een XOR-bewerking op los te laten.

[Rukapul]

offtopic:
SG->BV

Onbekend schreef op zaterdag 15 maart 2008 @ 23:21:
Ik zie nu pas dat de Engelse versie van die pagina veel meer informatie bevat dan de Nederlandse versie.
Met de meeste informatie wat daar in staat heb ik al rekening mee gehouden.

Grapjas Alle methods of cryptanalysis pas je niet zomaar even toe.

Peer-review is eigenlijk de enige goede wijze om de veiligheid van encryptiealgoritme te testen.

[ Voor 95% gewijzigd door Rukapul op 16-03-2008 11:46 ]

[Orion84]

Je algoritme is in elk geval voor zover ik kan zien niet echt goed bestand tegen een zogenaamde "known-plaintext attack". Daarbij weet de aanvaller dus zowel het bronbestand als de geëncrypte versie en probeert de sleutel te achterhalen.

Stap 1 kan iedereen. Stap 2 ook, alleen moet je alle 256 beginposities proberen, omdat je de key niet hebt.

Vervolgens heb je dus 256 mogelijke bestanden van vóór stap 3 en het bestand van na stap 3 heb je ook.

Als je op elk van de 256 bestanden een xor met de geëncrypte versie loslaat dan heb je de key, maar dan net zo vaak achter elkaar als nodig was natuurlijk, maar het patroon daarin zal makkelijk te zien zijn. Waardoor de aanvaller alle volgende bestanden die met dezelfde key versleuteld zijn kan ontcijferen.

Dit is een nogal theoretische aanval en is in lang niet alle praktijk situaties even toepasselijk, maar het geeft wel wat aan over je systeem. En door de manier waarop je algoritme werkt, hoeft niet eens de hele plaintext bekend te zijn, een gedeelte langer dan de lengte van de gebruikte key voldoet in feite al. En aangezien van bepaalde bestandstypes een deel van het bestand min of meer vastligt (headers en dergelijke), kan kennis over het type bestand al leiden tot het vinden van de key en dus het ontcijferen van het hele bestand.


Ik vermoed dat er nog wel meer aanvallen mogelijk zijn, behalve de "known-plaintext attack". Maar die zijn wat minder triviaal, zeker voor een zondagochtend

[ Voor 42% gewijzigd door Orion84 op 16-03-2008 12:16 ]

[Rukapul]

Ik heb maar 5 minuten naar je algoritme kunnen kijken (anders gaat Orion84 zo zeuren), maar het is in elk geval al niet compleet in de beschrijving. In stap 1 doe je een XOR met zichzelf met een positie verschoven. Deze stap is niet omkeerbaar als je niet uitlegt of je de meest linker originele byte ook ergens opslaat (en dus bij de bovenste een 0 aan het begin plaatst en bij de onderste een 0 aan het eind).

Dan de veiligheid:
- doe je wat ik hierboven noem dan is dat ook door een aanvaller om te keren en je wint er dus niets mee
- de effectieve keylengte is het kleinste gemeenste veelvoud van je key lengte (afgeleid van wachtwoord) en 256 (seed lengte). Bv key 16, seed 256 -> totale keylengte block: 256
- Bruce Schneier geeft in zijn boek Applied Crypto een (outline van een) eenvoudig algoritme om voor dit soort XOR algoritmes met vaste keylengtes de sleutel en het bericht te achterhalen. Een aanvaller moet voor dit algoritme alleen even de extra omkeerbare stappen uitvoeren.
- plus wat Orion84 zegt

[ Voor 8% gewijzigd door Rukapul op 16-03-2008 12:01 ]

[Onbekend]

Rukapul schreef op zondag 16 maart 2008 @ 11:43:

offtopic:
SG->BV

[...]

Grapjas Alle methods of cryptanalysis pas je niet zomaar even toe.

Peer-review is eigenlijk de enige goede wijze om de veiligheid van encryptiealgoritme te testen.

Ik bedoelde met die opmerking dat ik de huidige encryptie methodes in het achterhoofd heb gehouden. Ik heb ze niet toegepast omdat het zeer complex is.
Ik heb dus iets simpelers verzonnen, en daarvan wil ik eigenlijk weten waar de zwakke punten in zitten.

Orion84 schreef op zondag 16 maart 2008 @ 11:48:
Je algoritme is in elk geval voor zover ik kan zien niet echt goed bestand tegen een zogenaamde "known-plaintext attack". Daarbij weet de aanvaller dus zowel het bronbestand als de geëncrypte versie en probeert de sleutel te achterhalen.

Dan heb je ook niets meer aan de encryptie als je het bronbestand ook al hebt.

Orion84 schreef op zondag 16 maart 2008 @ 11:48:
Waardoor de aanvaller alle volgende bestanden die met dezelfde key versleuteld zijn kan ontcijferen.

Er wordt in het algemeen ook niet voor niets aanbevolen om voor alles een ander wachtwoord te verzinnen. Hiertegen kan je verder ook niets doen denk ik.

Rukapul schreef op zondag 16 maart 2008 @ 11:58:
Ik heb maar 5 minuten naar je algoritme kunnen kijken (anders gaat Orion84 zo zeuren), maar het is in elk geval al niet compleet in de beschrijving. In stap 1 doe je een XOR met zichzelf met een positie verschoven. Deze stap is niet omkeerbaar als je niet uitlegt of je de meest linker originele byte ook ergens opslaat (en dus bij de bovenste een 0 aan het begin plaatst en bij de onderste een 0 aan het eind).

Jawel, hij is compleet omkeerbaar.

Stel, dit is het origineel: 69, 101, 110, 84, 101, 115, 116, 46. (In Ascii: "EenTest.")
Dan zijn dit de waarden na stap 1: 32, 11, 58, 49, 22, 7, 90, 46.
Je ziet dat de rechter waarde het zelfde blijft omdat ik dan xor met 0x00.
Bij het terugvertalen, ga ik de reeks in omgekeerde richting af.
46 xor 0 = 46.
90 xor 46 = 116. Hierdoor heb ik mijn originele waarde terug.


Het is wel de bedoeling dat het wachtwoord uit minimaal zoveel bytes bestaat, omdat anders het heel gemakkelijk wordt om met brute force aan de gang te gaan.


@Orion84:
Op de rest van je post kom ik nog terug.

[CyBeR]

Onbekend schreef op zondag 16 maart 2008 @ 13:58:
[...]

Dan heb je ook niets meer aan de encryptie als je het bronbestand ook al hebt.

Zeker wel: dan kan ik de key vinden en andere files met dezelfde key gecrypt ook decrypten, zelfs zonder daar het origineel van te hebben. (En zoals gezegd, slechts een deel van de key kan genoeg zijn.)

[Onbekend]

Orion84 schreef op zondag 16 maart 2008 @ 11:48:
Je algoritme is in elk geval voor zover ik kan zien niet echt goed bestand tegen een zogenaamde "known-plaintext attack". Daarbij weet de aanvaller dus zowel het bronbestand als de geëncrypte versie en probeert de sleutel te achterhalen.

Stap 1 kan iedereen. Stap 2 ook, alleen moet je alle 256 beginposities proberen, omdat je de key niet hebt.

Vervolgens heb je dus 256 mogelijke bestanden van vóór stap 3 en het bestand van na stap 3 heb je ook.

Ik ga er vanuit dat iemand een gecodeerd bestand heeft onderschept, en wil decoderen.
Hierbij komen ze als eerste belemmering een wachtwoord tegen om de eerste decodeerstap te maken.

Orion84 schreef op zondag 16 maart 2008 @ 11:48:
Als je op elk van de 256 bestanden een xor met de geëncrypte versie loslaat dan heb je de key, maar dan net zo vaak achter elkaar als nodig was natuurlijk, maar het patroon daarin zal makkelijk te zien zijn. Waardoor de aanvaller alle volgende bestanden die met dezelfde key versleuteld zijn kan ontcijferen.

Dit is een nogal theoretische aanval en is in lang niet alle praktijk situaties even toepasselijk, maar het geeft wel wat aan over je systeem. En door de manier waarop je algoritme werkt, hoeft niet eens de hele plaintext bekend te zijn, een gedeelte langer dan de lengte van de gebruikte key voldoet in feite al. En aangezien van bepaalde bestandstypes een deel van het bestand min of meer vastligt (headers en dergelijke), kan kennis over het type bestand al leiden tot het vinden van de key en dus het ontcijferen van het hele bestand.

Als je het eerste gedeelte van de file kent (de headers dus), weet je al dat je op de goede weg zit. Vandaar dat ik drie stappen heb, waarvan de stap 1 afhankelijk is van foutloze data van de byte daarnaast. Je moet na de decodeerstappen 3 en 2, foutloze data hebben. Als je dat niet hebt, zullen er door de xor-bewerkingen geen juiste headers ontstaan.

Rukapul schreef op zondag 16 maart 2008 @ 11:58:
Dan de veiligheid:
- de effectieve keylengte is het kleinste gemeenste veelvoud van je key lengte (afgeleid van wachtwoord) en 256 (seed lengte). Bv key 16, seed 256 -> totale keylengte block: 256

Het is dan ook de bedoeling om een voldoende lang wachtwoord in te vullen. Een kort wachtwoord zal dan ook sneller te achterhalen zijn dan een lang wachtwoord. (Brute force)
Ik kan ook wel een seedfile met 16 bit getallen maken. Geen enkel probleem

[Orion84]

Ik geef niet voor niets al aan dat het in de praktijk misschien niet altijd even toepasbaar is? Verder is de aanname dat er toch wel steeds andere wachtwoorden zijn nogal een gevaarlijke

De 'betere' crypto systemen zijn wel degelijk tegen dergelijke aanvallen bestand. AES en RSA bijvoorbeeld.