Jag försöker förstå hur GRC-lösenordsgenerator kan få 512 bitars hemlig data samtidigt som 128-bitars data krypteras.
Generatoradressen finns här: https://www.grc.com/passwords.htm Se avsnittet ”Tekniska detaljer” i slutet av webbsidan.
De skrev:
Resultatet av kombinationen av den 256-bitars Rijndael / AES-hemliga nyckeln, det oigenkännliga (därför hemligt ) nuvärdet för den 128-bitars monotontillskridande räknaren, och den 128-bitars hemliga initialiseringsvektorn (IV) är 512 bitar av hemlig data som ger extremt hög säkerhet för genereringen av denna sidas ”perfekta lösenord”. Ingen kommer att ta reda på vilka lösenord du just har fått.
Diagram de ger: 
Det jag försökte är
Jag skapade en ny IV (128-bit):
Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]) En monolitisk räknare – vad som faktiskt är krypterat (128-bit):
Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01]) En krypteringsnyckel (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 monolitiska räknaren (eller det sista krypteringsresultatet med monolitiskt om det finns ett sista resultat).
De säger att det ger dem 512-bitars hemlig data. Men när jag krypterar allt får jag 16 byte (128-bitars) data:
<Buffer ad 86 de 83 23 1c 32 03 a8 6a e3 3b 72 1e aa 9f> Hur får de 512 bitar ”hemliga” data? Och hur de XOR 512bit data med 128-bitar från monolitisk räknare?
Svar
Och hur de XOR 512bit data med 128-bitar från monolitisk räknare?
Han gör inte det. Titta noga på algoritmen du postade. Alla XOR-operationer sker på 128 bitars värden. 256-bitarsinmatningen är nyckeln för en 256-bitars AES-implementering. SPDT-omkopplaren startar med den hemliga IV och växlar sedan till att köra med en 128-bitars räknare. från 512 = | IV | + | räknare | + | nyckel |. Det här är lite meningslöst eftersom han lägger in 512 bitar (påstådd) entropi och bara genererar ett lösenord på 128 bitar. Det är precis vad du har bevisat för dig själv. Typiskt är AES-CTR-PRNG-algoritmen som nedan (utan några omkopplare) och Steves metod är karakteristiskt ovanlig.
Hur får de 512 bitar av ”hemliga” data?
Vem vet? Det kallar troligen CryptGenRandom (Steve ”en Windows-man), men kanske är det bara hårt kodat någonstans. Och i montering är det ingen tvekan. Eller så kan det komma från hans Ultra-High Entropy Pseudo-Random Number Generator baserat på latinska rutor. En annan doozy.
Ingen kommer att ta reda på vilka lösenord du har har precis fått.
Räck efter saltet. Detta är helt klart falskt. Alla SSL-avlyssningsrouter längs linjen kan dekryptera och läsa webbtrafiken (på flyga). Och Steve vet också. Kanske är moralens i denna fråga – använd inte en webbtjänst för att få ditt lösenord eller nyckel från. Om du verkligen fastnar för en nyckel / lösenord, använd antingen tärningar eller bara slumpmässigt på tangenterna på tangentbordet. Det var tillräckligt bra för topphemliga engångskuddar under andra världskriget, så det borde räcka för dig.
Du har faktiskt ställt fel fråga. Du borde ha frågat vem är Steve Gibson? Google honom och ta reda på det. Det finns massor av artiklar. Jag kan inte skriva mer utan att offra min ro och professionalism.
Kommentarer
- Wow hahaha tack så mycket. Mycket intressant svar. Så jag borde inte ' inte lita på den här webbplatsen eftersom den ' är en webbplats utan också, och det här är det som kom ut på mig, eftersom webbplatsen försök att vara transparent genom att förklara hur de genererar nycklarna men misslyckades och bevisade att de var ganska fel när du gjorde det. Tack igen för din tid
- @ JeremyDicaire Du kanske vill titta på detta och kom ihåg det nästa gång du ser något GRC-relaterat …