Ik probeer te begrijpen hoe de GRC-wachtwoordgenerator 512 bit aan geheime data kan krijgen terwijl 128-bit data wordt versleuteld.
Het generatoradres bevindt zich hier: https://www.grc.com/passwords.htm Zie de sectie “De Techie Details” aan het einde van de webpagina.
Ze schreven:
Het resultaat van de combinatie van de 256-bit Rijndael / AES geheime sleutel, de onkenbare (dus geheime ) huidige waarde van de 128-bit monotoon oplopende teller, en de 128-bit geheime Initialization Vector (IV) is 512-bits geheime gegevens die een extreem hoge beveiliging bieden voor het genereren van de “perfecte wachtwoorden” van deze pagina. Niemand zal erachter komen welke wachtwoorden u zojuist heeft ontvangen.
Diagram dat ze bieden: 
Wat ik heb geprobeerd is
Ik heb een nieuwe IV (128-bit) gemaakt:
Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]) Een monolitische teller – wat is feitelijk versleuteld (128-bit):
Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01]) Een coderingssleutel (256-bit):, 32 bytes)
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]) Ze XOR de IV met de monolitische teller (of het laatste coderingsresultaat met de monolitische teller, als er een laatste resultaat is).
Ze zeggen dat het hun 512-bit geheime gegevens geeft. Maar als ik alles codeer, krijg ik 16 bytes (128-bits) aan gegevens:
<Buffer ad 86 de 83 23 1c 32 03 a8 6a e3 3b 72 1e aa 9f> Hoe krijgen ze 512 bits aan “geheime” gegevens? En hoe XOR 512bit aan gegevens met 128-bit van de monolitische teller?
Antwoord
En hoe ze 512bit aan gegevens XOR met 128-bits van de monolitische teller?
Dat doet hij niet. Kijk goed naar het algoritme u heeft gepost. Alle XOR-bewerkingen vinden plaats op 128-bits waarden. De 256-bits invoer is de sleutel voor een 256-bits AES-implementatie. De SPDT-schakelaar begint met het gebruik van de geheime IV en schakelt vervolgens over naar een 128-bits teller. De 512 bits worden geleverd van 512 = | IV | + | counter | + | key |. Dit is allemaal een beetje onzinnig aangezien hij 512 bits (vermeende) entropie invoert en slechts een wachtwoord van 128 bits genereert. Dit is precies wat je voor jezelf hebt bewezen. Typisch is het AES-CTR-PRNG-algoritme zoals hieronder (zonder schakelaars) en Steves methode is typisch ongebruikelijk.
Hoe krijgen ze 512 bit “geheime” gegevens?
Wie weet? Het is waarschijnlijk aanroepen naar CryptGenRandom (Steve “is een Windows-man), maar misschien is het ergens moeilijk gecodeerd. En bij montage geen twijfel mogelijk. Of het kan afkomstig zijn van zijn Ultrahoge entropie-generator voor pseudo-willekeurige getallen op basis van Latijnse vierkanten. Nog een doozy.
Niemand zal erachter komen welke wachtwoorden u gebruikt hebben net ontvangen.
Reik naar de salt. Dit is duidelijk niet waar. Elke SSL-interceptierouter langs de lijn kan het webverkeer decoderen en lezen (op de fly). En Steve weet het ook. Misschien is de moraal van deze vraag: gebruik geen webservice om uw wachtwoord of sleutel te verkrijgen. Als je echt vastzit aan een sleutel / wachtwoord, gebruik dan dobbelstenen of druk gewoon willekeurig op toetsen op het toetsenbord. Dat was goed genoeg voor topgeheime eenmalige pads tijdens WO II, dus het zou voor jou voldoende moeten zijn.
Je hebt eigenlijk de verkeerde vraag gesteld. Je had moeten vragen wie Steve Gibson is? Google hem en kom erachter. Er zijn massas artikelen. Ik kan niet meer schrijven zonder mijn kalmte en professionaliteit op te offeren.
Opmerkingen
- Wauw hahaha hartelijk dank. Zeer interessant antwoord. Dus ik zou ' deze website niet moeten vertrouwen omdat het ' een website is, maar ook, en dit is het ding dat bij mij uitkwam, omdat de website probeer transparant te zijn door uit te leggen hoe ze de sleutels hebben gegenereerd, maar dit is mislukt en bewees dat ze het helemaal bij het verkeerde eind hebben. Nogmaals bedankt voor je tijd
- @JeremyDicaire Misschien wil je eens kijken naar this en onthoud het de volgende keer dat u iets GRC-gerelateerd ziet …