Jeg er begynder inden for kryptografi. Jeg designede en adgangskodebaseret krypterings-dekrypteringsalgoritme, der bruger et tilfældigt salt og en adgangskode til at kryptere en besked. Jeg bruger SHA-512 til hashing, matrixoperationer til blanding, bitvis XOR til blanding af data og hentning. Længden af saltet og krypteringsteksten er 256 bogstaver.
Efter min viden er lavineffekt betyder, at en lille ændring i et af følgende:
- cipher
- password
- salt
skal ændre output drastisk.
Hvis jeg skifter salt eller kryptering i min implementering, kan jeg ikke se store ændringer i min produktion. Men når der er en lille ændring i adgangskoden, ændres output drastisk.
Så mine spørgsmål:
- Er min forståelse af lavineeffekten generelt korrekt? Hvis ikke, hvad skal det være?
- Hvad kan jeg gøre for bedst at producere lavineeffekten i min (eller hvilken som helst) kryptering? skal jeg reducere saltlængden mindre og generere en mindre krypteringstekst for at skabe en lavineeffekt? Hvis ikke, hvordan kan jeg opnå dette?
Kommentarer
- Af nysgerrighed, hvad bruger du hash til?
- Velkommen til Cryptography Stack Exchange. @Avinash, dit spørgsmål blev migreret her, fordi det er mere emne her end på Stack Overflow. Registrer din konto her for at kunne kommentere og acceptere et svar.
- Hvis du vil have konstruktive svar, skal du vise, hvordan din chiffer i øjeblikket fungerer (i matematiske formler, at foretrække). Så kan vi se på, hvordan vi kan forbedre det.
- Jeg ‘ har fjernet kommentarer i tråd med ” don ‘ t design din egen chiffer ” – her på krypto ‘ s helt acceptabelt at prøve, selvom du skal forstå, det er naturligvis på din egen risiko 🙂 Jeg ‘ har også redigeret spørgsmålet lidt for at fokusere mere på lavineeffekten i fravær af de relevante krypteringskonstruktioner. Hvis nogen føler, at det er unødvendigt, er du velkommen til at rulle tilbage og forbedre det, jeg ‘ har gjort.
Svar
Lad være med at ændre den faktiske krypteringsalgoritme. Læs om Kerckhoffs “princip : du skal skift kun ting som nøglen og IV, ikke den egentlige algoritme.
For at teste din lavine skal du vende en bit i din nøgle. Det skulle ændre ca. halvdelen af bitene i din output.
For chifferdesign er Anvendt kryptografi allerede blevet foreslået. Derudover skal du se på at introducere diffusion og forvirring i din algoritme. Det er også værd at studere eksisterende algoritmer for at se, hvordan de handler om tingene. Jeg startede med at designe min egen enkle Feistel-chiffer , på den måde er meget af den omgivende struktur allerede gjort for dig. Det forenkler også designet, idet F-funktionen ikke behøver at være inverterbar. Det giver dig meget mere fleksibilitet inden for dette område.
Advarslen om ikke at bruge dit eget design til andet end en læringsøvelse er god.
Kommentarer
- Endelig meget ….
- Cypher / cipher er en britisk / amerikansk ting.
Svar
Jeg synes det er fantastisk, at du bygger din egen krypterings-dekrypteringsalgoritme. Du lærer meget om krypto på den måde. Indtil videre har alle, der bygger en kryptokryptering-dekrypteringsalgoritme bygger noget forfærdeligt mangelfuldt på en eller anden måde – meget lærerigt – første gang.
terminologi
Hvis jeg forstår dit spørgsmål korrekt, har du en perfekt rimeligt spørgsmål om lavineeffekten, men de fleste mennesker på dette websted er så forvirrede over din ikke-standardterminologi, at de ikke engang kan forstå, hvad du spørger.
Hvis jeg forstår dit spørgsmål korrekt, du er ved at opbygge et krypterings-dekrypteringssystem, der tager almindelig tekst som input, gemmer data som krypterede filer og tillader derefter senere en person med den korrekte adgangskode at dekryptere de lagrede filer og gendanne dekrypteret almindelig tekst bit for bit identisk med den originale almindelige tekstindgang.
Som dig sandsynligvis allerede ved, opretter et typisk krypteringsprogram krypterede filer, der begynder med en initialiseringsvektor (IV), der blev frisk genereret af en kryptografisk sikker tilfældig talgenerator, da den krypterede fil blev oprettet.Krypteringsprogrammet hugger derefter inputfilen op i almindelige tekstblokke i nogle faste blocksize , bruger nogle blokciffreringstilstand af operation i “krypteringstilstand” til at behandle hver blok (og krypteringsnøglen) gennem en blokciffer for til sidst at ende med en krypteret blok af den samme blokstørrelse, som føjes til den krypterede fil. Der er ofte nogle fiddly bits i slutningen relateret til “polstring” og “meddelelsesgodkendelse”.
Senere hugger dekrypteringsprogrammet den krypterede fil op i krypterede blokke af den samme faste blokstørrelse, feeder hver blok ( og krypteringsnøglen) gennem blokcipher ved hjælp af den samme blockcipher-funktionstilstand i “dekrypteringstilstand” for at gendanne almindelig tekstblok og sammenkæder alle almindelige tekstblokke sammen for at gendanne en fil bit-for-bit identisk med den originale almindelige tekstfil .
Jeg bruger SHA-512 til hashing
OK, SHA-512 er en fremragende hashingalgoritme. Hvis du bruger dette som en del af den interne runde-funktion eller til at generere undernøgler fra hovedkrypteringsnøglen, ville det fungere. Det virker bare unødvendigt kompliceret.
Hvis du bruger SHA-512 som en nøgleafledningsfunktion (KDF) til at generere den vigtigste krypteringsnøgle fra adgangskoden, ville mange mennesker sige, at det ikke er kompliceret nok.
matrixoperationer til blandet
Det er lidt usædvanligt, men det kunne fungere.
bitvis XOR til blanding af data og hentning.
Næsten alle moderne krypteringsalgoritmer bruger masser af bitvise XOR-operationer. Mange moderne krypteringsalgoritmer er designet til kun at bruge modulære tilføjelser, rotation med faste rotationsmængder og XORer (ARX) i den indre sløjfe (rund iteration).
Jeg er ret så en indre rundefunktion, der bruger kun XOR eller kun rotation eller kun modulær tilføjelse vil være dødeligt usikker, uanset hvor mange runde iterationer der bruges.
(Jeg ved ikke nok til at fortælle noget om sikkerheden ved din særlige kombination af XOR og matrixoperationer).
Længden af salt og ciphertext er 256 bogstaver.
Jeg antager, at du mente at sige “Længden af initialiseringsvektoren (IV) og hver ciphertext-blok er 256 bogstaver . “
Et” salt “bruges i envejs kryptografisk hashing – se Kan du hjælpe mig med at forstå, hvad en kryptografisk ” salt ” er? . En “IV” bruges i tovejs kryptografi – både kryptering og dekryptering. Både “salt” og “IV” er frisk genererede tilfældige værdier, der antages at være offentligt kendte, men terminologien antyder, at de vil blive brugt i forskellige slags systemer.
Næsten meget indstiller længden af IV er lig med blokstørrelsen, så det er fantastisk.
Min forståelse er, at praktisk talt alle cifre, der blev udviklet før AES-konkurrencen i 1997, brugte en blokstørrelse på 64 bit (8 byte) eller mindre. Nogle kryptografer troede tilsyneladende, at det ikke var nok, men så vidt jeg ved, ser alle ud til at tro, at en blokstørrelse på 128 bit (16 byte) er tilstrækkelig.
En blokstørrelse på 256 byte ville fungere; det virker bare unødvendigt stort.
lavineeffekten
Når du kører hver blok med almindelig tekst gennem blokchifteren (i en eller anden krypteringstilstand) betyder lavineeffekten, at en enkelt bit ændres i et af følgende:
- data i almindelig tekstblok
- adgangskode
- IV
skal ændre output ciphertext block drastisk (ca. halvdelen af bitene).
Når du kører hver blok af ciphertext gennem blokcipheren (i en eller anden dekrypteringstilstand) betyder lavineeffekten, at en enkelt bit ændres i et af følgende:
- ciphertext block
- password
- IV
skal ændre output “plaintext” -blokken drastisk (ca. halvdelen af bitene).
Hvis jeg skifter salt eller kryptering i min implementering, ser jeg ikke nogen store ændringer i min produktion.
Jeg gætter på, at du mente at sige en af to ting:
- “hvis jeg skifter en enkelt bit nær begynder o f den krypterede fil (dvs. i IV eller i en tidlig ciphertext-blok) kan jeg ikke se nogen store ændringer i slutningen af min output-plaintext-fil.
Denne mangel på ændringer sker altid, når du bruger (sikker) chifferblokering (CBC) eller andre driftsformer. Så det er ikke nødvendigvis et problem.
Dette kan dog være et problem, hvis du troede, du brugte brug af (sikker) Propagating Cipher Block Chaining (PCBC) -tilstand, hvor denne manglende ændring indikerer en fejl i implementeringen.
Også denne manglende ændring er det forventede resultat, når du bruger (usikker) Electronic Codebook (ECB) -tilstand.
Uanset hvilken driftsmåde du vælger, dekrypteringsprogrammet skal udskrive store skræmmende advarsler om, at filen mislykkedes med MAC-godkendelseskontrollen, når en enkelt bit af den krypterede fil er beskadiget.
- “hvis jeg ændrer en enkelt bit i en enkelt krypteret ciphertext-blok i en krypteret fil, kan jeg ikke se nogen store ændringer i den tilsvarende plaintext-blok i min output-plaintext-fil. “
Ja, dette indikerer en alvorlig fejl – blokcifferalgoritme har ikke en god lavineeffekt. Dette er et tegn på, at algoritmen ikke har tilstrækkelig blanding. Dette betyder generelt, at systemet er sårbart over for valgt ciphertext-angreb og lignende angreb.
Hvad kan jeg gøre for bedst at frembringe lavineeffekten i min (eller hvilken som helst) kryptering? skal jeg reducere saltlængden mindre og generere en mindre krypteringstekst for at skabe en lavineeffekt?
Jeg antager, at du mente at spørge “skal jeg reducere størrelsen på IV og blokstørrelsen for at skabe en lavineeffekt? “
Det er generelt ikke nødvendigt.
De mest almindelige tilgange til at producere lavineeffekten er anført i Wikipedia blokciffer -artikel:
Jeg kender ikke nogen blokciffer, der producerer en fuld lavine efter en enkelt runde. Personer, der designer blokkoder, forsøger at vælge et antal runder, der er tilstrækkelige til at få blokcifringen til at modstå alle standard kryptografiske angreb , hvilket er mere end tilstrækkeligt til at producere en fuld lavine .
Folk, der designer en blokciffer, vælger typisk en generel ordning for blokcipher-design og får blokcipher-programmet til at gentage det igen og igen det valgte antal runder. Nogle af de mest populære generelle skemaer for blokcifferdesign er:
- substitutionspermutationsnetværk
- Feistel-chiffer
- Lai-Massey-chiffer
Hver af disse kræver en vis intern ikke-lineær funktion. Tidlige blokkoder bruger ofte nogle komplicerede interne funktioner på hver runde, der næsten opnår lavine i en enkelt runde. Moderne chifre bruger ofte en meget enkel, hurtig intern funktion hver runde (et par ARX-funktioner) med lige nok ikke-linearitet til i sidste ende at opnå lavine efter et stort antal runder.
Kommentarer
- Sidebemærkning: khazad-chiffer har fuld diffusion efter en enkelt runde. Jeg ‘ har lavet legetøj, der gør det også, det ‘ er bestemt muligt, og det er sjovt at finde måder at gøre det på.