Hoe kan ik mijn cijfer het lawine-effect laten zien?

Doe geen moeite om het eigenlijke coderingsalgoritme te wijzigen. Lees meer over het principe van Kerckhoffs “principe : je zou moeten verander alleen dingen zoals de sleutel en de IV, niet het eigenlijke algoritme.

Om je lawine te testen, draai je een bit in je sleutel. Dat zou ongeveer de helft van de bits in uw uitvoer moeten veranderen.

Voor coderingsontwerp is Applied Cryptography al voorgesteld. Daarnaast moet je kijken naar het introduceren van diffusie en verwarring in je algoritme. Het is ook de moeite waard om bestaande algoritmen te bestuderen om te zien hoe ze de dingen aanpakken. Ik begon met het ontwerpen van mijn eigen eenvoudige Feistel-cijfer , op die manier is veel van de omringende structuur al voor je gedaan. Het vereenvoudigt ook het ontwerp, doordat de F-functie niet omkeerbaar hoeft te zijn. Dat geeft je veel meer flexibiliteit op dat gebied.

De waarschuwing dat je je eigen ontwerp niet voor iets anders dan een leeroefening moet gebruiken, is een goede.

Opmerkingen

• Hartelijk bedankt ….
• Cypher / cipher is iets voor het VK / de VS.

Ik vind het geweldig dat je je eigen coderings-decoderingsalgoritme bouwt. Op die manier leer je veel over crypto. Tot dusver heeft iedereen die een crypto-encryptie-decoderingsalgoritme bouwt de eerste keer iets gruwelijk gebrekkig op de een of andere manier – zeer leerzaam -.

terminologie

Als ik je vraag goed begrijp, heb je een perfecte redelijke vraag over het lawine-effect, maar de meeste mensen op deze site zijn zo in de war over uw niet-standaard terminologie dat ze “niet eens kunnen begrijpen wat u vraagt.

Als ik uw vraag goed begrijp, je bouwt een encryptie-decoderingssysteem dat neemt platte tekst als invoer, slaat gegevens op als versleutelde bestanden, en laat later iemand met het juiste wachtwoord toe om die opgeslagen bestanden te ontsleutelen en ontsleutelde platte tekst bit-voor-bit te herstellen, identiek aan de originele platte-tekstinvoer.

Zoals jij waarschijnlijk al weet, maakt een typisch versleutelingsprogramma versleutelde bestanden die beginnen met een initialisatievector (IV) die pas werd gegenereerd door een cryptografisch beveiligde generator voor willekeurige getallen toen het versleutelde bestand werd gemaakt.Het versleutelingsprogramma hakt het invoerbestand vervolgens op in platte tekstblokken van een vaste blokgrootte , gebruikt een blokcoderingsmodus van bewerking in “coderingsmodus” om elk blok (en de coderingssleutel) te verwerken via een blokcijfer om uiteindelijk te eindigen met een gecodeerd blok van dezelfde blokgrootte, die wordt toegevoegd aan het versleutelde bestand. Er zijn vaak een paar onhandige stukjes aan het einde die verband houden met “opvulling” en “berichtauthenticatie”.

Later hakt het decoderingsprogramma het gecodeerde bestand op in gecodeerde blokken van dezelfde vaste blokgrootte, en voedt elk blok ( en de versleutelingssleutel) door de blokversleuteling met behulp van dezelfde blokversleutelingsmodus in ontsleutelingsmodus om het leesbare tekstblok te herstellen, en voegt alle leesbare tekstblokken samen om een bestand bit-voor-bit te herstellen dat identiek is aan het originele platte tekstbestand .

Ik “gebruik SHA-512 voor hashing

OK, SHA-512 is een uitstekend hash-algoritme. Als je dit gebruikt als onderdeel van de interne ronde-functie, of om subsleutels te genereren vanuit de hoofdversleutelingssleutel, zou het werken; het lijkt gewoon onnodig ingewikkeld.

Als je SHA-512 gebruikt als een sleutelafleidingsfunctie (KDF) om de belangrijkste coderingssleutel van het wachtwoord te genereren, zouden veel mensen zeggen dat het niet “gecompliceerd genoeg is.

matrixbewerkingen voor in willekeurige volgorde afspelen

Dat is nogal ongebruikelijk, maar dat zou kunnen werken.

bitsgewijze XOR voor het mixen en ophalen van gegevens.

Vrijwel alle moderne versleutelingsalgoritmen gebruiken veel bitsgewijze XOR-bewerkingen. Veel moderne versleutelingsalgoritmen zijn ontworpen om alleen modulaire toevoegingen te gebruiken, rotatie met vaste rotatiehoeveelheden en XORs (ARX) in de binnenste lus (ronde iteratie).

Ik vind het mooi dat een interne ronde functie die alleen XOR, of alleen rotatie, of alleen modulaire toevoeging, zal fataal onveilig zijn, ongeacht hoeveel ronde iteraties er worden gebruikt.

(Ik weet niet genoeg om iets te vertellen over de beveiliging van uw specifieke combinatie van XOR- en matrixbewerkingen).

De lengte van de salt en de cijfertekst is 256 letters.

Ik neem aan dat je bedoelde te zeggen “De lengte van de initialisatievector (IV) en elk cijfertekstblok is 256 letters . “

Een” salt “wordt gebruikt in cryptografische hashing in één richting – zie Kun je me helpen begrijpen wat een cryptografische ” salt ” is? . Een “IV” wordt gebruikt bij tweewegscryptografie – zowel codering als decodering. Zowel “salt” als “IV” zijn vers gegenereerde willekeurige waarden waarvan wordt aangenomen dat ze algemeen bekend zijn, maar de terminologie geeft aan dat ze in verschillende soorten systemen zullen worden gebruikt.

Vrijwel iedereen stelt de lengte in van de IV is gelijk aan de blokgrootte, dus dat is geweldig.

Ik heb begrepen dat praktisch alle cijfers die zijn ontwikkeld vóór de aankondiging van de AES-wedstrijd in 1997 een blokgrootte van 64 bits (8 bytes) of minder gebruikten. Sommige cryptografen dacht blijkbaar dat dat niet genoeg was, maar voor zover ik weet lijkt iedereen nu te denken dat een blokgrootte van 128 bits (16 bytes) voldoende is.

Een blokgrootte van 256 bytes zou werken; het lijkt gewoon onnodig groot.

het lawine-effect

Wanneer elk blok platte tekst door het blokcijfer wordt gehaald (in een of andere coderingsmodus), betekent het lawine-effect dat een enkele bit verandert in een van de volgende:

• gegevens in het platte tekstblok
• wachtwoord
• IV

moet de voer het cijfertekstblok drastisch uit (ongeveer de helft van de bits).

Wanneer elk blok cijfertekst door het blokcijfer wordt gehaald (in een bepaalde decoderingsmodus), betekent het lawine-effect dat een enkele bit verandert in een van de volgende:

• cijfertekstblok
• wachtwoord
• IV

moet het output “plaintext” blok drastisch veranderen (ongeveer de helft van de bits).

Als ik in mijn implementatie het salt of de cipher verander, zie ik geen grote veranderingen in mijn uitvoer.

Ik vermoed dat je een van de volgende twee dingen wilde zeggen:

• “als ik een enkel bit verander in de buurt van de begin o f het versleutelde bestand (dat wil zeggen, in de IV of in een vroeg gecodeerd tekstblok), “zie ik geen grote veranderingen aan het einde van mijn output-leesbare tekstbestand.”

Dit gebrek aan verandering gebeurt altijd bij gebruik van de (beveiligde) Cipher Block Chaining (CBC) of een andere bedieningsmodus. Het is dus niet per se een probleem.

Dit kan echter een probleem zijn als u dacht dat u de (beveiligde) Propagating Cipher Block Chaining (PCBC) -modus gebruikte, waarbij dit gebrek aan verandering duidt op een bug in implementatie.

Dit gebrek aan verandering is ook het verwachte resultaat bij gebruik van de (onveilige) Electronic Codebook (ECB) -modus.

Welke modus je ook kiest, het decoderingsprogramma zou grote enge waarschuwingen moeten afdrukken dat het bestand de MAC-authenticatiecontrole niet doorstaat wanneer een enkel bit van het gecodeerde bestand beschadigd is.

• “als ik een enkel bit verander in een enkel gecodeerd cijfertekstblok in een gecodeerd bestand, “zie ik geen grote veranderingen in het corresponderende platte tekstblok in mijn output platte tekstbestand.”

Ja, dit duidt op een ernstige fout – de blokcijferalgoritme heeft geen goed lawine-effect. Dit is een teken dat het algoritme niet voldoende mengt. Dit betekent over het algemeen dat het systeem kwetsbaar is voor selected-ciphertext attack en soortgelijke aanvallen.

Wat kan ik doen om het lawine-effect het beste in mijn (of enig) cijfer te produceren? moet ik de zoutlengte minder verkorten en een kleinere cijfertekst genereren om een lawine-effect te creëren?

Ik neem aan dat je wilde vragen “moet ik de grootte van de IV en de blokgrootte om een lawine-effect te creëren? “

Dat is over het algemeen niet nodig.

De meest gebruikelijke benaderingen om het lawine-effect te produceren zijn vermeld in de Wikipedia blokcijfer artikel:

Ik ken geen blokcijfer dat na een enkele ronde een volledige lawine produceert. Mensen die blokcijfers ontwerpen, proberen een aantal ronden voldoende te kiezen om ervoor te zorgen dat de blokcijfer bestand is tegen alle standaard cryptografische aanvallen , wat meer dan voldoende is om een volledige lawine te veroorzaken .

Mensen die een blokcijfer ontwerpen, kiezen doorgaans één algemeen blokcijferontwerpschema, en laten het blokcijferprogramma dit herhalen over het geselecteerde aantal rondes. Enkele van de meest populaire ontwerpschemas voor algemene blokcijfers zijn:

• substitutie-permutatienetwerk
• Feistel-cijfer
• Lai-Massey-cijfer

Elk van deze vereist een interne niet-lineaire functie. Vroege blokcijfers gebruiken vaak een ingewikkelde interne functie in elke ronde die bijna in een enkele ronde lawine veroorzaakt. Moderne cijfers gebruiken vaak elke ronde een zeer eenvoudige, snelle interne functie (een paar ARX-functies) met net genoeg niet-lineariteit om uiteindelijk na een groot aantal ronden lawine te veroorzaken.

Opmerkingen

• Kanttekening: het khazad-cijfer is na een enkele ronde volledig verspreid. Ik ‘ heb speelgoed gemaakt dat het ook doet, het is ‘ zeker mogelijk, en manieren ontdekken om dat te doen is leuk.