Jeg prøver å forstå hvordan GRC-passordgenerator kan få 512 bit hemmelige data mens du krypterer 128-bit data.

Generatoradressen ligger her: https://www.grc.com/passwords.htm Se delen «The Techie Details» på slutten av websiden.

De skrev:

Resultatet av kombinasjonen av den 256-biters Rijndael / AES-hemmelige nøkkelen, det ukjente (derfor hemmelige ) nåverdien av den 128-biters monotontrinnende telleren, og den 128-biters hemmelige initialiseringsvektoren (IV) er 512-bits hemmelige data som gir ekstremt høy sikkerhet for genereringen av denne sidens «perfekte passord». Ingen kommer til å finne ut hvilke passord du nettopp har mottatt.

Diagram de gir: Diagram over krypteringsprosessen

Det jeg prøvde er

Jeg laget en ny IV (128-bit):

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

En monolitisk teller – hva som faktisk er kryptert (128-bit):

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

En krypteringsnøkkel (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 telleren (eller det siste krypteringsresultatet med den monolitiske teller, hvis det er et siste resultat).

De sier det gir dem 512-biters 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 telleren?

Svar

Og hvordan de XOR 512bit data med 128-bit fra den monolitiske telleren?

Han gjør ikke det. Se nøye på algoritmen du postet. Alle XOR-operasjoner skjer på 128-biters verdier. 256-biters oppføring er nøkkelen for en 256-biters AES-implementering. SPDT-bryteren begynner å bruke den hemmelige IV og går deretter over til å kjøre med en 128 bit-teller. fra 512 = | IV | + | teller | + | nøkkel |. Alt dette er litt meningsløst da han legger inn 512 biter (påstått) entropi og bare genererer et passord på 128 bits. Dette er nøyaktig hva du har bevist for deg selv. Vanligvis er AES-CTR-PRNG-algoritmen som nedenfor (uten brytere), og Steves metode er karakteristisk uvanlig.

aes ctr prng

Hvordan får de 512 bit av «hemmelige» data?

Hvem vet? Det kaller nok CryptGenRandom (Steve «en Windows-mann), men kanskje er det bare hardt kodet et sted. Og i montering er det ingen tvil. Eller det kan komme fra hans Ultra-High Entropy Pseudo-Random Number Generator basert på Latin Squares. Nok en doozy.

Ingen kommer til å finne ut hvilke passord du har nettopp har mottatt.

Nå saltet. Dette er helt klart falskt. Enhver SSL-avlyttingsruter langs linjen kan dekryptere og lese nettrafikken (på fly). Og Steve vet også. Moralen i dette spørsmålet er kanskje – ikke bruk en nettjeneste for å få passordet eller nøkkelen din fra. Hvis du virkelig sitter fast for en nøkkel / et passord, bruk enten terning eller bare trykk tilfeldig på tastene på tastaturet. Det var bra nok til topphemmelige engangspadser under andre verdenskrig, så det burde være nok for deg.

Du har faktisk stilt feil spørsmål. Du burde ha spurt hvem er Steve Gibson? Google ham og finn ut. Det er masser av artikler. Jeg kan ikke skrive mer uten å ofre min ro og profesjonalitet.

Kommentarer

  • Wow hahaha tusen takk. Veldig interessant svar. Så jeg skal ikke ' ikke stole på dette nettstedet fordi det ' er et nettsted, men også, og dette er tingen som kom ut på meg, fordi nettstedet prøv å være gjennomsiktig ved å forklare hvordan de genererer nøklene, men mislyktes, og beviste at de var ganske gale mens du gjorde det. Takk igjen for tiden
  • @JeremyDicaire Det kan være lurt å ta en titt på dette og husk det neste gang du ser noe GRC-relatert …

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *