Spørgsmål:
Lagring af adgangskode sammen med krypteret fil
Oliver.m
2016-12-29 22:01:32 UTC
view on stackexchange narkive permalink

Jeg lavede et lille program til at kryptere filer og løb ind i problemet med at kontrollere, at den angivne nøgle er den rigtige, når jeg dekrypterer. Min idé var at gemme den (polstrede, krypterede) nøgle sammen med den krypterede fil, så når du vil dekryptere, kontrollerer programmet først, om det første par byte (ikke-polstret) svarer til den medfølgende nøgle. Jeg er ingen sikkerhedsekspert, og jeg kan ikke se et problem med fremgangsmåden, men jeg har stadig en fornemmelse af, at dette ville være en dårlig praksis, hvordan.

Er denne tilgang OK set ud fra et sikkerhedsperspektiv? Er der måske allerede en anden løsning på det oprindelige problem?

Tre svar:
Polynomial
2016-12-29 22:06:16 UTC
view on stackexchange narkive permalink

Selvom der ikke er nogen åbenbar sårbarhed her, er en bedre mulighed simpelthen at gemme en statisk streng snarere end selve nøglen. Hvis en angriber finder et sidekanalangreb, der giver dem mulighed for at opdage en blok med almindelig tekst, vil din tilgang lækker adgangssætningen og dermed bryde hele systemet, hvorimod indstillingen fast tekst ikke ville.

FWIW, dette er den metode, som TrueCrypt bruger.
Ikke sikker på statisk.I filmen The Imitation Game sagde de, at den tyske kryptering var blevet brudt på grund af statiske præfikser til nogle krypterede meddelelser, og vi ved ikke, hvilken slags cypher OP vil bruge.Måske er præfikset lig med tilfældig x, og nogle f (x) ville være bedre.
@SergeSeredenko Dette er kun tilfældet med svage kryptosystemer, såsom Enigma, som er sårbare over for angreb med almindelig tekst.Moderne cifre (fx AES, DES) er stærkt modstandsdygtige over for angreb med kendt almindelig tekst.
Jeg er enig, men OP nævnte ikke AES eller DES.Måske xorserer han filen med nøglen, spørgsmålet blev stillet ret abstrakt.
@SergeSeredenko I hvilket tilfælde kryptosystemet ville blive skruet * uanset * brugen af begge skemaer, så valget er overflødigt på det tidspunkt.
Jeg er ikke helt enig.Hvis jeg lagrede mine adgangskoder, som jeg havde tilfældigt genereret tilfældigt, i binær struktur med nogle hovedadgangskoder, tror jeg ikke, det ville være muligt at knække filen.Medmindre jeg selvfølgelig lægger noget konstant underlag der.Alligevel nævnte jeg lige, at dit råd ikke er universelt, det er alt.
@SergeSeredenko En sådan ordning ville være knækkelig, når adgangskodeordbogen oversteg en bestemt størrelse, simpelthen ved at finde nøglebyte, der producerer gyldige binære strukturer, der kun indeholder ASCII-strenge.Hver nøglebyte kunne opdages uafhængigt af hinanden for at være en del af et lille kendt sæt og producerede (samlet) kun et par hundrede eller tusind mulige hovedadgangskoder.Hvis hovedadgangskoden har nogen struktur, kan den sande adgangskode udledes heraf.Hvis ikke, kunne kandidater sammenlignes med enhver fanget offline-hash.
@SergeSeredenko Derudover ville man forvente, at dine adgangskoder ville have brugernavne eller tjenestenavne forbundet med dem inden for databasen, og det ville derfor være trivielt at udlede kendt tekst.
@SergeSeredenko Bare for at validere mine tanker skrev jeg en kode, der genererede 10.000 tilfældige adgangskodedatabaser, der hver indeholder 30 adgangskoder med en længde på mellem 20 og 40 tegn (tilfældig) ved hjælp af en ordbog med a-z, AZ, 0-9 plus 29 ASCII-symboler.Hvert listeelement afgrænses af et null, dog uden efterfølgende null.Disse databaser blev krypteret ved hjælp af en gentagelses-xor af en adgangskode på 22 tegn (blandet bogstav, tal og symboler).I 3 tilfælde kunne jeg gendanne adgangskoden endeligt.Den bedste sag var et nøgleområde i størrelsen 409.227.831.936.000 - stadig en 3x10 ^ 28. af adgangskodens nøgleområde.
Hvad med polstring til en bestemt blokstørrelse?De fleste cifre har brug for polstring, og polstringsfejl kan let genkendes.
@JonasKöritz Hvad henviser du til?Det hypotetiske gentagne xor-system?Eller OP's system?Hvis det er den gentagne xor, gør det at bryde det trivielt: polstringen vil kræve nogle kendte polstringsstrukturer, som afslører nøglebyte direkte.
Forsøg på at dekryptere data med forkert polstring ville medføre fejl, hvorfor skulle han overhovedet gemme nøglen?
@JonasKöritz Åh, du taler om OP's ordning.Problemet der er, at du introducerer en sårbarhed med polstring af orakel, hvis du gør det forkert.
Han ser ud til at lave sin egen krypt, det ville allerede gøre det forkert.
ThoriumBR
2016-12-29 22:28:40 UTC
view on stackexchange narkive permalink

Du kan gøre dette:

  1. Generer kryptografisk sikker tilfældig 128-byte-nøgle

  2. Generer hash af tilfældig nøgle

  3. Krypter filen med den tilfældigt genererede nøgle

  4. Krypter den tilfældige nøgle med den brugernøgle

  5. Sæt følgende værdier i filen:

    krypteret tilfældig nøgle: tilfældig nøgle hash: krypterede fildata

  6. ol>

    Når du vil dekryptere dataene, bruger du de data, der er leveret af brugeren, til at dekryptere den krypterede tilfældige nøgle, hvorefter du hash dem og sammenligner med den gemte hash. Hvis de er de samme, bruger du den nu dekrypterede tilfældige nøgle til at dekryptere dataene.

"hash: krypterede fildata" burde det ikke være "hash: tilfældig nøgle"?
@idmean Jeg forstod det som `krypter (tilfældig nøgle, brugernøgle) + ':' + hash (tilfældig nøgle) + ':' + krypter (data, tilfældig nøgle) ', hvor': 'bare er en afgrænser.
@GustavoRodrigues Selvfølgelig ser jeg det nu.Jeg læste det som en slags nøgleværdipar.
bot47
2016-12-30 01:21:17 UTC
view on stackexchange narkive permalink

Inkludering af en statisk streng lyder som om den kunne være sårbar over for et kendt almindeligt tekstangreb. I stedet for ville jeg til følgende (men ville være glad for at høre, om det er en dårlig idé!);

  1. Hash din almindelige tekst og læg hash'en på den
  2. Krypter alt med din krypteringsteknik

Når du dekrypterer det, skal du kontrollere, om hashen i starten matcher den hash, du forventer. Dette gør dig i stand til at opdage, om du har den rigtige dekrypteringsnøgle, og som et plus får du integritetskontrol gratis. Hvis du vil fremskynde dette, skal du sige, at du gerne vil kryptere store mængder data, hvor det ikke er muligt at køre en hashing-funktion over hele nyttelasten, reducere den hashede del til et par megabyte eller blokke, hvis det er en blokcypher .

Hvis du tilføjer en ukrypteret hash af selve nøglen til filen, kan angribere teste nøgler uden at skulle dekryptere hele filen. Dette vil fremskynde angrebene meget.

Hvad du beskriver, er i det væsentlige en godkendt kryptering.Jeg tror, at godkendt kryptering er det rigtige værktøj til opgaven.Men jeg er ikke sikker på, at den metode, du beskriver, faktisk vil producere en sikker godkendt kryptering.Jeg har bestemt stødt på anbefalinger til at bruge design, hvor dataene godkendes, inden du begynder at dekryptere.


Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...