Jeg prøver at forstå, hvordan GRC-adgangskodegenerator kan få 512 bit hemmelige data, mens de krypterer 128-bit data.

Generatoradressen findes her: https://www.grc.com/passwords.htm Se afsnittet “Tekniske detaljer” i slutningen af websiden.

De skrev:

Resultatet af kombinationen af 256-bit Rijndael / AES hemmelig nøgle, det ukendte (derfor hemmelige ) nutidsværdien af den 128-bit monotontilvækstæller, og den 128-bit hemmelige initialiseringsvektor (IV) er 512-bit af hemmelige data, der giver ekstremt høj sikkerhed for genereringen af denne sides “perfekte” adgangskoder. Ingen vil finde ud af, hvilke adgangskoder du lige har modtaget.

Diagram, de giver: Diagram over krypteringsprocessen

Det jeg prøvede er

Jeg lavede en ny IV (128-bit):

Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]) 

En monolitisk tæller – hvad der faktisk er krypteret (128-bit):

Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01]) 

En krypteringsnøgle (256-bit):, 32 byte)

Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]) 

De XOR IV med den monolitiske tæller (eller det sidste krypteringsresultat med den monolitiske tæller, hvis der er et sidste resultat).

De siger, at det giver dem 512-bit hemmelige data. Men når jeg krypterer alt, får jeg 16 byte (128-bit) data:

<Buffer ad 86 de 83 23 1c 32 03 a8 6a e3 3b 72 1e aa 9f> 

Hvordan får de 512 bit “hemmelige” data? Og hvordan de XOR 512bit data med 128-bit fra den monolitiske tæller?

Svar

Og hvordan de XOR 512bit data med 128-bit fra den monolitiske tæller?

Han gør det ikke. Se nøje på algoritmen du sendte. Alle XOR-operationer forekommer på 128 bit-værdier. 256-bit-indtastningen er nøglen til en 256-bit AES-implementering. SPDT-kontakten starter ved hjælp af den hemmelige IV og skifter derefter til at køre med en 128 bit-tæller. 512 bit kommer fra 512 = | IV | + | tæller | + | nøgle |. Dette er alt sammen noget meningsløst, da han lægger 512 bits (påstået) entropi og kun genererer et kodeord på 128 bit. Dette er præcis, hvad du har bevist for dig selv. Typisk er AES-CTR-PRNG-algoritmen som nedenfor (uden omskiftere), og Steves metode er karakteristisk usædvanlig.

aes ctr prng

Hvordan får de 512 bit af “hemmelige” data?

Hvem ved? Det kalder sandsynligvis CryptGenRandom (Steve “en Windows-mand), men måske er det bare hårdt kodet et eller andet sted. Og i forsamlingen er det ingen tvivl. Eller det kan komme fra hans Ultra-High Entropy Pseudo-tilfældig talgenerator baseret på latinske firkanter. En anden doozy.

Ingen vil finde ud af, hvilke adgangskoder du har lige har modtaget.

Nå ud til saltet. Dette er tydeligt falsk. Enhver SSL-opsnappende router langs linjen kan dekryptere og læse webtrafikken (på flyve). Og Steve ved også. Måske er moralen i dette spørgsmål – Brug ikke en webservice til at få din adgangskode eller nøgle fra. Hvis du virkelig sidder fast med en nøgle / adgangskode, skal du enten bruge terninger eller bare tilfældigt trykke på tasterne på tastaturet. Det var godt nok til tophemmelige engangspuder under 2. verdenskrig, så det skulle være tilstrækkeligt for dig.

Du har faktisk stillet det forkerte spørgsmål. Du skulle have spurgt, hvem der er Steve Gibson? Google ham og find ud af det. Der er masser af artikler. Jeg kan ikke skrive mere uden at ofre min ro og professionalisme.

Kommentarer

  • Wow hahaha mange tak. Meget interessant svar. Så jeg skal ikke ' ikke stole på dette websted, fordi det ' er et websted, men også, og det er den ting, der kom ud på mig, fordi hjemmesiden prøv at være gennemsigtig ved at forklare, hvordan de genererer nøglerne, men mislykkedes, og beviste, at de er ret forkerte, mens du gør det. Tak igen for din tid
  • @JeremyDicaire Du vil måske se på dette og husk det næste gang du ser noget GRC-relateret …

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *