Jeg er nysgjerrig på en algoritme som vil være bra for følgende scenario:
- 32-biters «ren tekst» inngang, hentet fra en teller
- 32 eller 64-biters «ciphertext» -utgang
- Det skal være mulig å dekryptere utdataene med nøkkelen (og muligens noen få andre skjulte parametere, som en forskyvning og gjeldende teller), og returner den opprinnelige 32-bits tellerverdien
- En bruker observerer aldri inngangen, men kan motta et hvilket som helst antall utganger, muligens sekvensiell. Likevel bør de ikke være i stand til å vet hvilke indekser de har.
- Det skal være vanskelig å gjette andre utganger som tilsvarer gyldige motverdier.
Min utrente intuisjon er at siden nøkkelen og utgangene er større enn inngangsplassen, bør det være ganske enkelt å ha «gode» resultater, i hvert fall for de første utgangene. Det virker imidlertid også logisk at med nok eksempler kan nøkkelen og indeksene beregnes enkelt, men jeg forventer de fleste tilfeller å bruke l ess enn 100 verdier.
Mine spørsmål er:
- Er det noen eksisterende algoritmer som fungerer for dette scenariet?
- Hvor vanskelig ville det være å sprekk? Dvs beregne verdier som dekrypteres til gyldige indekser.
- Hvor mye påvirker besittelsen av flere prøver effektiviteten til å knekke den?
-
Hva er galt med en naiv tilnærming? som:
u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37Forutsatt at tillegg brytes rundt 64-biters heltallsgrenser. Det virker som om det vil blande tilfeldig nøkkel grundig med en enkelt inngang, men har mer enn en output kan raskt øke informasjonen en angriper besitter, selv om jeg ikke vet hvordan. Åpenbart vil det bli ødelagt, jeg prøver bare å lære.
- Ville bruke en nøkkelavhengig verdi for venstre rotasjon, som
(((key & 0xFFFE)+1) * 37)bli bedre? Hvor mye hjelper det og hvorfor? - Hvilke tilnærminger, ressurser osv. Vil du bruke til å analysere algoritmen og utforme en bedre?
Kommentarer
- Dette er veldig mye et XY-problem slik du beskriver det. En CSPRNG (merk S) ser ikke ' ut til å være en god løsning for dette i det hele tatt. Nøkkelstørrelsesforespørselen er litt rar, hvorfor er det ikke mulig å bruke større nøkkelstørrelser?
- Jeg antar at nøkkelstørrelsen ikke er viktig. Jeg håpet at 64-biters nøkkel ville være nok til å kryptere en 32-biters verdi.
Svar
- Er det noen eksisterende algoritmer som fungerer for dette scenariet?
Ja, faktisk , det er et antall 64 biters blokkodere. Standard visdom er at de ikke oppfordres til generell bruk, fordi standard blokkeringsmodi har en tendens til å begynne å lekke informasjon når du nærmer deg bursdagen (i dette tilfellet ca. 30 GB), men for din brukstilfelle ville det ikke være en bekymring.
Her er noen alternativer:
-
3DES (aka TDES); dette er DES brukt tre ganger med tre forskjellige taster; dette har fordelen av å være veldig godt studert.
-
Speck som har parametersett med 64-biters blokkiffer. Dette har fordelen av å være det raskeste alternativet, og ble designet av folk som vet at de gjør, og har gjort det overraskende mye kryptanalyse.
-
En FPE-kryptering (som f.eks. FF1, som kan håndtere hvilken som helst vilkårlig blokkstørrelse (inkludert 64 bits). Dette har fordelen ved at de tillater muligheten for en finjustering (som er et praktisk sted å plassere de «andre skjulte parametrene», hvis du bestemmer deg for at det er en fordel ). Det er tregere enn alternativene; med FF1 kommer sikkerheten fra den underliggende sikkerheten til AES, pluss den påviselige sikkerheten til Feistel-strukturen.
Nå tar disse tastene lenger enn 64 bits; den vanlige visdommen er at en 64-biters nøkkel bare ikke er lang nok.
- Hvor vanskelig ville det være å knekke? Dvs. beregne verdier som dekrypteres til gyldige indekser.
For noe av det ovennevnte vil det eneste praktiske alternativet en motstander ha være å gjett tilfeldig krypteringstekst, og håper å snuble på en som dekrypterer til en gyldig indeks.
- Hvor mye koster besittelsen av flere prøver påvirker effektiviteten til å knekke den?
For noe av det ovennevnte vil det å ha store mengder prøver fremdeles gjøre angrepet mulig.
- Hva er galt med en naiv tilnærming som …
ARX-krypter (faktisk hvilken som helst kryptering, men spesielt ARX) er vanskelig å få rett. Spesielt ARX-krypterer har en tendens til ikke å være gode til å forstyrre differensielle og lineære egenskaper (noe som betyr at slike design må virkelig studeres for å sikre at det gjør det).
- Hvilke tilnærminger, ressurser osv. vil du bruke til å analysere algoritmen og designe en bedre?
Jeg foreslår at du går med et design som allerede er analysert. Jeg lister opp tre ovenfor.
Kommentarer
- Jeg ' foretrekker f.eks. Blowfish fremfor 3DES hvis det er en endring av relativt liten nøkkelinngang. Sikkerheten til 3DES ville være tvilsom selv om -tasten ble utvidet til 128 bits (eller rettere sagt 112 bits, selvfølgelig).
- @MaartenBodewes: har du et sitat på noen som viser at 3DES med en ukjent nøkkel som skiller seg fra en tilfeldig jevn permutasjon?
- Nei, selvfølgelig ikke. Imidlertid, jeg ' vil heller ikke engang måtte resonnere om krypteringen min har ~ 80 bit eller ~ 112 bit styrke når du mates en 128 bit eller 192 bit nøkkel (I ' har vi ikke tvil om at du ville være i stand til å gjøre det, men hei, vi re ikke alle poncho). Og nøkkelstørrelse ser ut til å være et problem i spørsmålet. Bare å kaste paritetsbitene i så fall er bortkastet.
- Kan du utdype uttalelsen " Nå tar disse nøklene lenger enn 64 bits; den vanlige visdommen er at en 64-biters nøkkel bare ikke er lang nok. "? Hvilke algoritmer krever nøkler med hvilke lengder, og 64bit nøkler er ikke lange nok til hva, akkurat?
- @shader: nøkler på bare 64 bits er sårbare fra brute force-søk fra store (godt finansierte) motstandere. Fordi det generelt er enkelt nok å bruke noe større nøkler (f.eks. 128 bit) som ikke er ' t sårbare for alle, velger vi generelt det sikrere alternativet (selv om vi ' er ikke umiddelbart bekymret for at NSA vil være interessert i å angripe oss, eller om Amazon bestemmer seg for å vie hele skyen til oss …