Ik “ben benieuwd naar een algoritme dat goed zou zijn voor het volgende scenario:
- 32-bits” platte tekst ” invoer, afkomstig van een teller
- 32- of 64-bits “cijfertekst” uitvoer
- Het zou mogelijk moeten zijn om de uitvoer te ontsleutelen met de sleutel (en mogelijk een paar andere verborgen parameters, zoals een offset en huidige teller), en retourneert de originele 32-bits tellerwaarde
- Een gebruiker observeert nooit de invoer, maar kan een willekeurig aantal outputs ontvangen, mogelijk sequentieel. Toch zouden ze niet in staat moeten zijn om weten welke indices ze hebben.
- Het zou moeilijk moeten zijn om andere outputs te raden die overeenkomen met geldige tellerwaarden.
Mijn ongetrainde intuïtie is dat, aangezien de sleutel en outputs zijn groter dan de invoerruimte, zou het vrij eenvoudig moeten zijn om goede resultaten te krijgen, in ieder geval voor de eerste paar uitvoer. Het lijkt echter ook logisch dat met voldoende steekproeven de sleutel en indices gemakkelijk kunnen worden berekend, maar ik verwacht dat de meeste gevallen te gebruiken l meer dan 100 waarden.
Mijn vragen zijn:
- Zijn er bestaande algoritmen die werken voor dit scenario?
- Hoe moeilijk zou het zijn om barst? Dat wil zeggen, bereken waarden die decoderen naar geldige indices.
- In hoeverre beïnvloedt het bezit van meer monsters de efficiëntie van het kraken ervan?
-
Wat is er mis met een naïeve benadering zoals:
u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37Ervan uitgaande dat optellen rond 64-bits integergrenzen loopt. Het lijkt alsof het de willekeurige sleutel grondig zou mengen met een enkele invoer, maar er meer dan één zou hebben output zou de informatie die een aanvaller bezit snel kunnen vergroten, hoewel ik niet zou weten hoe. Het is duidelijk dat het kapot gaat, ik probeer gewoon te leren.
- Zou een sleutelafhankelijke waarde gebruiken voor de rotatie naar links, zoals
(((key & 0xFFFE)+1) * 37)beter zijn? Hoeveel helpt het en waarom? - Welke benaderingen, bronnen, enz. Zou u gebruiken om zowel het algoritme te analyseren als een beter algoritme te ontwerpen?
Opmerkingen
- Dit is in hoge mate een XY-probleem zoals je het beschrijft. Een CSPRNG (let op de S) lijkt hier helemaal niet ‘ t een goede oplossing voor te zijn. Het verzoek om sleutelgrootte is een beetje raar, waarom is het niet mogelijk om grotere sleutelgroottes te gebruiken?
- Ik veronderstel dat de sleutelgrootte niet essentieel is. Ik hoopte dat de 64-bits sleutel voldoende zou zijn om een 32-bits waarde te versleutelen.
Antwoord
- Zijn er bestaande algoritmen die werken voor dit scenario?
Ja, eigenlijk , zijn er een aantal 64-bits blokcijfers. De standaard wijsheid is dat ze niet worden aangemoedigd voor algemeen gebruik, omdat standaard blokcoderingsmodi de neiging hebben om informatie te lekken wanneer je bijna de verjaardag nadert (in dit geval ongeveer 30 Gbytes); maar voor jouw gebruik zou dat niet zorg.
Hier zijn enkele opties:
-
3DES (ook bekend als TDES); dit is DES driemaal toegepast met drie verschillende sleutels; dit heeft het voordeel zeer goed bestudeerd te zijn.
-
Speck die parametersets heeft met 64 bit blokcijfers. Dit heeft de voordeel dat het het snelste alternatief is, en is ontworpen door mensen die weten dat ze “bezig zijn met en hebben gedaan door een verrassende hoeveelheid cryptoanalyse.
-
Een FPE-codering (zoals FF1, die elke willekeurige blokgrootte aankan (inclusief 64 bits). Dit heeft het voordeel dat ze de mogelijkheid bieden voor een tweak (wat een handige plaats is om de “andere verborgen parameters” te plaatsen, mocht u besluiten dat dit een voordeel is ). Het is langzamer dan de alternatieven; met FF1 komt de beveiliging voort uit de onderliggende beveiliging van AES, plus de aantoonbare beveiliging van de Feistel-structuur.
Nu nemen deze sleutels langer dan 64 bits; de algemene wijsheid is dat een 64-bits sleutel gewoon niet lang genoeg is.
- Hoe moeilijk zou het zijn om te kraken? Dat wil zeggen, bereken waarden die decoderen naar geldige indices.
Voor elk van de bovenstaande zou de enige praktische optie die een tegenstander zou hebben, zijn om raad willekeurig cijferteksten en hoop er een tegen te komen die decodeert naar een geldige index.
- Hoeveel kost het bezit van beïnvloeden meer samples de efficiëntie van het kraken ervan?
Voor elk van de bovenstaande zal het hebben van grote hoeveelheden samples de aanval nog steeds onhaalbaar maken.
- Wat is er mis met een naïeve benadering zoals …
ARX-coderingen (eigenlijk elke codering, maar vooral ARX) zijn lastig om goed te krijgen. Vooral ARX-coderingen zijn meestal niet goed in het verstoren van differentiële en lineaire kenmerken (wat betekent dat dergelijke ontwerp zou echt goed bestudeerd moeten worden om er zeker van te zijn dat dit het geval is).
- Welke benaderingen, bronnen, enz. zou je gebruiken om zowel het algoritme te analyseren als een beter algoritme te ontwerpen?
Ik zou willen voorstellen dat je kiest voor een ontwerp dat al is geanalyseerd; ik noem er drie hierboven.
Opmerkingen
- Ik ‘ geef de voorkeur aan bijvoorbeeld Blowfish boven 3DES als er een wijziging is van relatief kleine sleutelinvoer. De beveiliging van 3DES zou twijfelachtig zijn, zelfs als de -sleutel werd uitgebreid naar 128 bits (of liever 112 bits natuurlijk).
- @MaartenBodewes: heb je een citaat van iemand die die 3DES laat zien met een onbekende sleutel die te onderscheiden is van een willekeurige gelijkmatige permutatie?
- Nee, natuurlijk niet. Ik ‘ hoef echter niet eens te redeneren als mijn codering ~ 80 bit of ~ 112 bit sterkte bij invoer van een 128 bit of 192 bit sleutel (ik ‘ twijfel er niet aan dat je dit zou kunnen doen, maar hey, we re niet allemaal poncho). En de sleutelgrootte lijkt een probleem te zijn in de vraag. Gewoon de pariteitsbits weggooien is in dat geval een verspilling.
- Kunt u wat meer zeggen over de verklaring ” Nu, deze nemen sleutels langer dan 64 bits; de algemene wijsheid is dat een 64-bits sleutel gewoon niet lang genoeg is. “? Welke algoritmen vereisen sleutels van welke lengte, en waarvoor zijn 64-bits sleutels niet lang genoeg, precies?
- @shader: sleutels van slechts 64 bits zijn kwetsbaar voor brute force-zoekopdrachten van grote (goed gefinancierde) tegenstanders. Omdat het over het algemeen eenvoudig genoeg is om wat grotere sleutels te gebruiken (bijv. 128 bit) die voor niemand ‘ kwetsbaar zijn, kiezen we over het algemeen voor de veiligere optie (zelfs als we ‘ zijn niet onmiddellijk bezorgd dat de NSA geïnteresseerd zal zijn om ons aan te vallen, of dat Amazon zal besluiten hun volledige cloud aan ons te wijden …