Hur kan jag få min chiffer att visa lavineffekten?

Jag är nybörjare i kryptografi. Jag utformade en lösenordsbaserad krypterings-dekrypteringsalgoritm, som använder ett slumpmässigt salt och ett lösenord för att kryptera ett meddelande. Jag använder SHA-512 för hashing, matrisoperationer för blandning, bitvis XOR för blandning av data och hämtning. Saltets längd och krypteringstexten är 256 bokstäver.

Såvitt jag vet är lavineffekt betyder att en liten förändring av något av följande:

  • chiffer
  • lösenord
  • salt

måste ändra produktionen drastiskt.

I min implementering, om jag byter salt eller kryptering, ser jag inga stora förändringar i min produktion. Men när det sker en liten förändring av lösenordet ändras utdata drastiskt.

Så, mina frågor:

  • Är min förståelse av lavineffekten i allmänhet korrekt? Om inte, vad ska det vara?
  • Vad kan jag göra för att bäst producera lavineffekten i min (eller någon) chiffer? ska jag minska saltlängden mindre och skapa en mindre krypteringstext för att skapa en lavineffekt? Om inte, hur kan jag uppnå detta?

Kommentarer

  • Av nyfikenhet, vad använder du hash för?
  • Välkommen till Cryptography Stack Exchange. @Avinash, din fråga migrerades hit eftersom den är mer på ämnet här än på Stack Overflow. Registrera ditt konto här för att kunna kommentera och acceptera ett svar.
  • Om du vill ha några konstruktiva svar bör du visa hur din chiffer för närvarande fungerar (i matematiska formler, helst). Sedan kan vi titta på hur vi kan förbättra det.
  • Jag ’ har tagit bort kommentarer i linje med ” don ’ t designa din egen chiffer ” – här på krypto ’ s helt acceptabelt att försöka, även om du borde förstå att det är helt på egen risk förstås 🙂 Jag ’ har också redigerat frågan lite för att fokusera mer på lavineffekten i frånvaro relevanta krypteringskonstruktioner. Om någon känner att det är onödigt kan du gärna rulla tillbaka och förbättra det jag ’ har gjort.

Svar

Bry dig inte om att ändra den faktiska krypteringsalgoritmen. Läs om Kerckhoffs ”princip : du borde ändra bara saker som nyckeln och IV, inte den faktiska algoritmen.

För att testa din lavin, vänd en bit i din nyckel. Det borde ändra ungefär hälften av bitarna i din utdata.

För chifferdesign har Tillämpad kryptografi redan föreslagits. Förutom att du måste titta på att införa diffusion och förvirring i din algoritm. Det är också värt att studera befintliga algoritmer för att se hur de går till saker. Jag började med att designa min egen enkla Feistel-kodning , så görs en hel del av den omgivande strukturen redan för dig. Det förenklar också designen genom att F-funktionen inte behöver vara inverterbar. Det ger dig mycket mer flexibilitet inom detta område.

Varningen om att inte använda din egen design för något annat än en inlärningsövning är bra.

Kommentarer

  • Än så mycket ….
  • Cypher / cipher är en brittisk / amerikansk sak.

Svar

Jag tycker att det är fantastiskt att du bygger din egen krypterings-dekrypteringsalgoritm. Du kommer att lära dig mycket om krypto på det sättet. Hittills har alla som bygger en krypterings kryptering-dekrypteringsalgoritm bygger något på ett eller annat sätt fruktansvärt – mycket lärorikt – första gången.

terminologi

Om jag förstår din fråga korrekt har du en perfekt rimlig fråga om lavineffekten, men de flesta på denna webbplats är så förvirrade över din icke-standardiserade terminologi att de inte ens kan förstå vad du frågar.

Om jag förstår din fråga korrekt, du bygger ett krypterings-dekrypteringssystem som tar klartext som inmatning, lagrar data som krypterade filer och tillåter sedan någon med rätt lösenord att dekryptera de lagrade filerna och återställa dekrypterad klartext bit för bit identisk med den ursprungliga klartextinmatningen.

Som du förmodligen redan vet, skapar ett typiskt krypteringsprogram krypterade filer som börjar med en initialiseringsvektor (IV) som nyligen genererades av en kryptografiskt säker slumpgenerator när den krypterade filen skapades.Krypteringsprogrammet hugger sedan in inmatningsfilen i klartextblock i vissa fasta blockstorlek , använder något blockkrypteringsläge för drift i ”krypteringsläge” för att bearbeta varje block (och krypteringsnyckeln) genom en blockkodning för att så småningom få ett krypterat block av samma blockstorlek, som läggs till den krypterade filen. Det finns ofta några fiffiga bitar i slutet relaterade till ”padding” och ”meddelandeautentisering”.

Senare huggar dekrypteringsprogrammet upp den krypterade filen till krypterade block med samma fasta blockstorlek, matar varje block ( och krypteringsnyckeln) genom blockkrypteringen med samma blockkrypteringsläge i ”dekrypteringsläge” för att återställa klartextblocket och sammanfogar alla klartextblock för att återställa en fil bit-för-bit identisk med den ursprungliga klartextfilen .

Jag använder SHA-512 för hashing

OK, SHA-512 är en utmärkt hashingalgoritm. Om du använder detta som en del av den interna runda funktionen eller för att generera undernycklar från huvudkrypteringsnyckeln skulle det fungera. Det verkar bara onödigt komplicerat.

Om du använder SHA-512 som en nyckelderiveringsfunktion (KDF) för att generera huvudkrypteringsnyckeln från lösenordet, många skulle säga att det inte är tillräckligt komplicerat.

matrisoperationer för blanda

Det är typ av ovanligt, men det kan fungera.

bitvis XOR för blandning av data och hämtning.

Praktiskt taget alla moderna krypteringsalgoritmer använder många bitvisa XOR-operationer. Många moderna krypteringsalgoritmer är utformade för att endast använda modulära tillägg, rotation med fasta rotationsbelopp och XOR (ARX) i den inre slingan (rund iteration).

Jag är ganska bra som en inre rundfunktion som använder endast XOR, eller endast rotation, eller endast modulärt tillägg, är dödligt osäker oavsett hur många runda iterationer som används.

(Jag vet inte tillräckligt för att berätta någonting om säkerheten för just din kombination av XOR och matrisoperationer).

Längden på salt och ciphertext är 256 bokstäver.

Jag antar att du menade att säga ”Längden på initialiseringsvektorn (IV) och varje chiffertextblock är 256 bokstäver . ”

Ett” salt ”används i envägs kryptografisk hashing – se Kan du hjälpa mig att förstå vilken kryptografisk ” salt ” är? . En ”IV” används i tvåvägskryptering – både kryptering och dekryptering. Både ”salt” och ”IV” är nyligen genererade slumpmässiga värden som antas vara allmänt kända, men terminologin antyder att de kommer att användas i olika typer av system.

Nästan alla ställer in längden på IV är lika med blockstorleken, så att det är bra.

Min uppfattning är att praktiskt taget alla cifrar som utvecklats före AES-tävlingsmeddelandet 1997 använde en blockstorlek på 64 bitar (8 byte) eller mindre. tyckte tydligen att det inte var tillräckligt, men så vitt jag vet verkar alla nu tro att en blockstorlek på 128 bitar (16 byte) är tillräcklig.

En blockstorlek på 256 byte skulle fungera; det verkar bara onödigt stort.

lavineffekten

När du kör varje block av klartext genom blockchiffran (i något krypteringsläge) innebär lavineffekten att en enda bit förändras i något av följande:

  • data i klartextblocket
  • lösenord
  • IV

måste ändra utdata ciphertext block drastiskt (ungefär hälften av bitarna).

När du kör varje block av ciphertext genom blockcipher (i något dekrypteringsläge) betyder lavineffekten att en enda bit förändras i något av följande:

  • ciphertext block
  • lösenord
  • IV

måste ändra utdata ”plaintext” block drastiskt (ungefär halva bitarna).

Om jag byter salt eller kryptering i min implementering ser jag inga stora förändringar i min produktion.

Jag antar att du tänkte säga en av två saker:

  • ”om jag byter en bit nära börjar o f den krypterade filen (dvs i IV eller i något tidigt ciphertext-block) ser jag inte några stora förändringar mot slutet av min output-klartextfil.

Denna brist på förändring sker alltid när man använder (säker) Chifferblockkedjning (CBC) eller andra driftsätt. Så det är inte nödvändigtvis ett problem.

Detta kan dock vara ett problem om du trodde att du använde (säkert) PCB-läge (Propagating Cipher Block Chaining), där denna brist på förändring indikerar en fel i implementeringen.

Denna brist på förändring är också det förväntade resultatet när du använder (osäker) elektronisk kodbok (ECB).

Oavsett vilket driftsätt du väljer, dekrypteringsprogrammet borde skriva ut stora läskiga varningar om att filen misslyckades med MAC-autentiseringskontrollen när någon bit av den krypterade filen skadades.

  • ”om jag byter en bit i en enda krypterade ciphertext-block i en krypterad fil ser jag inga stora förändringar i motsvarande plaintext-block i min output-plaintext-fil.

Ja, detta indikerar en allvarlig brist – blockkrypteringsalgoritmen har inte en bra lavineffekt. Detta är ett tecken på att algoritmen inte har tillräcklig blandning. Detta innebär i allmänhet att systemet är sårbart för valgt ciphertext-attack och liknande attacker.

Vad kan jag göra för att bäst producera lavineffekten i min (eller någon) chiffer? ska jag minska saltlängden mindre och generera en mindre ciffertext för att skapa en lavineffekt?

Jag antar att du tänkte fråga ”om jag skulle minska storleken på IV och blockstorleken för att skapa en lavineffekt? ”

Är det vanligtvis inte nödvändigt.

De vanligaste metoderna för att producera lavineffekten listas i Wikipedia blockcipher -artikel:

Jag känner inte till någon blockcipher som producerar en full lavin efter en enda omgång. Personer som utformar blockkodare försöker välja ett visst antal omgångar som är tillräckliga för att blockkrypteringen ska motstå alla standardkryptografiska attacker , vilket är mer än tillräckligt för att producera en fullständig lavin .

Personer som utformar en blockchiffer väljer vanligtvis ett generellt blockschifferdesignschema och får blockcipher-programmet att upprepa det om och om igen det valda antalet rundor. Några av de mest populära allmänna scheman för blockchifferdesign är:

  • substitutionspermutationsnätverk
  • Feistel-chiffer
  • Lai-Massey-chiffer

Var och en av dessa kräver en viss intern icke-linjär funktion. Tidiga blockkoder använder ofta någon komplicerad intern funktion i varje omgång som nästan uppnår lavin i en enda omgång. Moderna cifrar använder ofta en mycket enkel, snabb intern funktion varje runda (några ARX-funktioner) med precis tillräcklig olinjäritet för att så småningom uppnå lavin efter ett stort antal omgångar.

Kommentarer

  • Sidanot: khazad-chiffer har full spridning efter en enda omgång. Jag ’ har gjort leksaker som gör det också, det ’ är verkligen möjligt, och att upptäcka sätt att göra det är roligt.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *