Hvordan kan jeg få krypteringen min til å vise skredeffekten?

Ikke bry deg med å endre selve krypteringsalgoritmen. Les om Kerckhoffs «prinsipp : du bør bare endre ting som nøkkelen og IV, ikke selve algoritmen.

For å teste skredet ditt, snu en bit i nøkkelen. Det bør endre omtrent halvparten av bitene i utdataene dine.

For krypteringsdesign har Applied Cryptography allerede blitt foreslått. I tillegg til at du må se på å introdusere diffusjon og forvirring i algoritmen din. Det er også verdt å studere eksisterende algoritmer for å se hvordan de går til ting. Jeg startet med å designe min egen enkle Feistel-kryptering , på den måten er mye av den omkringliggende strukturen allerede gjort for deg. Det forenkler også designet ved at F-funksjonen ikke trenger å være inverterbar. Det gir deg mye mer fleksibilitet i dette området.

Advarselen om å ikke bruke ditt eget design til noe annet enn en læringsøvelse er god.

Kommentarer

• Endelig mye ….
• Cypher / cipher er en britisk / amerikansk ting.

Jeg synes det er fantastisk at du bygger din egen krypterings-dekrypteringsalgoritme. Du vil lære mye om krypto på den måten. Så langt har alle som bygger en kryptokryptering-dekrypteringsalgoritme bygger noe forferdelig feil på en eller annen måte – veldig lærerikt – første gang.

terminologi

Hvis jeg forstår spørsmålet ditt riktig, har du en perfekt rimelig spørsmål om skredeffekten, men de fleste på dette nettstedet er så forvirret over den ikke-standardiserte terminologien din at de ikke engang kan forstå hva du spør.

Hvis jeg forstår spørsmålet ditt riktig, du bygger et krypterings-dekrypteringssystem som tar ren tekst som inndata, lagrer data som krypterte filer, og lar senere noen med riktig passord dekryptere de lagrede filene og gjenopprette dekryptert ren tekst bit for bit identisk med den originale ren tekstinntastingen.

sannsynligvis allerede vet, oppretter et typisk krypteringsprogram krypterte filer som begynner med en initialiseringsvektor (IV) som ble nylig generert av en kryptografisk sikker tilfeldig tallgenerator da den krypterte filen ble opprettet.Krypteringsprogrammet hugger deretter inndatafilen til klartekstblokker av noen faste blokkeringsstørrelser , bruker noen blokkeringsmodus for drift i «krypteringsmodus» for å behandle hver blokk (og krypteringsnøkkelen) gjennom en blokkryptering for til slutt å ende opp med en kryptert blokk med den samme blokkstørrelsen, som er lagt til den krypterte filen. Det er ofte noen fiffige biter på slutten relatert til «polstring» og «meldingsautentisering».

Senere hugger dekrypteringsprogrammet opp den krypterte filen i krypterte blokker av samme faste blokkstørrelse, mater hver blokk ( og krypteringsnøkkelen) gjennom blokkrypteringen ved å bruke den samme blokkrypteringsmodusen i «dekrypteringsmodus» for å gjenopprette klartekstblokken, og sammenkoble alle klartekstblokkene sammen for å gjenopprette en fil bit for bit identisk med den originale ren tekstfilen .

Jeg bruker SHA-512 for hashing

OK, SHA-512 er en utmerket hashingalgoritme. Hvis du bruker dette som en del av den interne rundefunksjonen, eller for å generere undernøkler fra hovedkrypteringsnøkkelen, vil det fungere. Det virker bare unødvendig komplisert.

Hvis du bruker SHA-512 som en nøkkelavledningsfunksjon (KDF) for å generere hovedkrypteringsnøkkelen fra passordet, vil mange si at den ikke er komplisert nok.

matriseoperasjoner for blande

Det er litt uvanlig, men det kan fungere.

bitvis XOR for blanding av data og henting.

Praktisk talt alle moderne krypteringsalgoritmer bruker mange bitvise XOR-operasjoner. Mange moderne krypteringsalgoritmer er designet for kun å bruke modulære tillegg, rotasjon med faste rotasjonsmengder og XOR (ARX) i den indre sløyfen (rund iterasjon).

Jeg er ganske så en indre rundefunksjon som bruker bare XOR, eller bare rotasjon, eller bare modulær tillegg, vil være dødelig usikker uansett hvor mange runde iterasjoner som brukes.

(Jeg vet ikke nok til å fortelle noe om sikkerheten til din spesielle kombinasjon av XOR og matriseoperasjoner).

Lengden på salt og krypteringstekst er på 256 bokstaver.

Jeg antar at du mente å si «Lengden på initialiseringsvektoren (IV) og hver krypteringstekstblokk er 256 bokstaver . «

Et» salt «brukes i enveis kryptografisk hashing – se Kan du hjelpe meg med å forstå hva en kryptografisk » salt » er? . En «IV» brukes i toveiskryptografi – både kryptering og dekryptering. Både «salt» og «IV» er nylig genererte tilfeldige verdier som antas å være offentlig kjent, men terminologien antyder at de vil bli brukt i forskjellige typer systemer.

Nesten alle setter lengden på IV er lik blokkstørrelsen, slik at det er flott.

Min forståelse er at praktisk talt alle kodere som ble utviklet før kunngjøringen om AES 1997 brukte en blokkstørrelse på 64 bits (8 byte) eller mindre. Noen kryptografer trodde tilsynelatende ikke det var nok, men så vidt jeg vet ser alle ut til å tro at en blokkstørrelse på 128 bits (16 byte) er tilstrekkelig.

En blokkstørrelse på 256 byte ville fungert; det virker bare unødvendig stort.

skredeffekten

Når du kjører hver blokk med ren tekst gjennom blokkrypteringen (i noen krypteringsmodus), betyr skredeffekten at en enkeltbit endres i noe av det følgende:

• data i klartekstblokken
• passord
• IV

må endre output ciphertext block drastically (omtrent halvparten av bitene).

Når du kjører hver blokk av ciphertext gjennom blokkrypteringen (i en eller annen dekrypteringsmodus), betyr skredeffekten at en enkeltbit endres i noe av det følgende:

• krypteringstekstblokk
• passord
• IV

må endre utgangen «ren tekst» -blokk drastisk (ca. halvparten av biter).

Hvis jeg bytter salt eller kryptering i implementeringen min, ser jeg ikke noen store endringer i utdataene mine.

Jeg antar at du mente å si en av to ting:

• «hvis jeg endrer en enkelt bit i nærheten av begynnelse o f den krypterte filen (dvs. i IV eller i en tidlig ciphertext-blokk), ser jeg ikke noen store endringer mot slutten av min output-tekstfil. «

Denne mangelen på endring skjer alltid når du bruker (sikker) krypteringsblokkjetting (CBC) eller andre driftsmåter. Så det er ikke nødvendigvis et problem.

Dette kan imidlertid være et problem hvis du trodde du brukte (sikker) Propagating Cipher Block Chaining (PCBC) -modus, der denne mangelen på endring indikerer en feil i implementeringen.

Også denne mangelen på endring er det forventede resultatet når du bruker (usikker) elektronisk kodebok (ECB) -modus.

Uansett hvilken driftsmåte du velger, dekrypteringsprogrammet skal skrive ut store skumle advarsler om at filen mislyktes i MAC-godkjenningskontrollen når en enkelt bit av den krypterte filen er skadet.

• «hvis jeg endrer en enkelt bit i en enkelt kryptert ciphertext-blokk i en kryptert fil, ser jeg ikke store endringer i den tilsvarende plaintext-blokken i min output-plaintext-fil. «

Ja, dette indikerer en alvorlig feil – block cipher algoritme har ikke god skredeffekt. Dette er et tegn på at algoritmen ikke har tilstrekkelig miksing. Dette betyr generelt at systemet er sårbart for valgt ciphertext-angrep og lignende angrep.

Hva kan jeg gjøre for å best produsere skredeffekten i (eller hvilken som helst) kryptering? skal jeg redusere saltlengden mindre og generere en mindre krypteringstekst for å skape en skredeffekt?

Jeg antar at du mente å spørre «skal jeg redusere størrelsen på IV og blokkstørrelsen for å skape en skredeffekt? «

Det er generelt ikke nødvendig.

De vanligste tilnærmingene for å produsere skredeffekten er oppført i Wikipedia block cipher artikkel:

Jeg kjenner ikke noen blocksiffer som produserer et fullt skred etter en enkelt runde. Personer som designer blokkodere prøver å velge et antall runder som er tilstrekkelig til å få blokkrypteringen til å motstå alle standard kryptografiske angrep , noe som er mer enn tilstrekkelig til å produsere et fullt skred .

Personer som designer en blokkryptering, velger vanligvis ett generelt utformingsskjema for blokkryptering, og får blokkrypteringsprogrammet til å gjenta det om og om igjen det valgte antall runder. Noen av de mest populære generelle skjemaene for blokkryptering er:

• substitusjonspermutasjonsnettverk
• Feistel-kryptering
• Lai-Massey-kryptering

Hver av disse krever noen intern ikke-lineær funksjon. Tidlige blokkrypter bruker ofte noen kompliserte interne funksjoner på hver runde som nesten oppnår skred i en enkelt runde. Moderne kodere bruker ofte en veldig enkel, rask intern funksjon hver runde (noen få ARX-funksjoner) med akkurat nok ikke-linearitet til å til slutt oppnå skred etter et stort antall runder.

Kommentarer

• Sideanmerkning: khazad-kryptering har full diffusjon etter en enkelt runde. Jeg ‘ har laget leker som gjør det også, det ‘ er absolutt mulig, og å oppdage måter å gjøre det på er morsomt.