oktober 28, 2020
Articles
Ingen kommentarer

Hvordan krypteres 64bit-værdier symmetrisk?

Jeg er nysgerrig efter en algoritme, der ville være godt for følgende scenarie:

  1. 32-bit “almindelig tekst” input, taget fra en tæller
  2. 32 eller 64-bit “ciphertext” -udgang
  3. Det skal være muligt at dekryptere output med nøglen (og muligvis et par andre skjulte parametre, f.eks. en forskudt og aktuel tæller), og returner den originale 32-bit tællerværdi
  4. En bruger observerer aldrig input, men kan modtage et vilkårligt antal output, muligvis sekventielt. Alligevel skulle de ikke være i stand til ved, hvilke indekser de har.
  5. Det skulle være svært at gætte andre output, der svarer til gyldige tællerværdier.

Min utrænede intuition er, at da nøglen og output er større end input-pladsen, skal det være ret let at have “gode” resultater, i det mindste for de første par output. Det ser dog også ud til at være logisk, at nøglen og indekserne kunne beregnes let med nok eksempler, men jeg forventer de fleste tilfælde at bruge l ess end 100 værdier.

Mine spørgsmål er:

  1. Er der nogen eksisterende algoritmer, der fungerer i dette scenarie?
  2. Hvor svært ville det være at sprække? Det vil sige, beregne værdier, der dekrypteres til gyldige indekser.
  3. Hvor meget påvirker besiddelsen af flere prøver effektiviteten af at revne det?

  4. Hvad er der galt med en naiv tilgang ligesom: 

    u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37

    Under forudsætning af, at tilføjelse omslutter 64-bit heltalsgrænser. Det ser ud til, at det grundigt vil blande tilfældig nøgle med en enkelt input, men at have mere end en output kunne hurtigt øge den information, som en angriber besidder, selvom jeg ikke ved hvordan. Det er klart, at det bliver brudt, jeg prøver bare at lære.

  5. Ville bruge en nøgleafhængig værdi til venstre rotation, som (((key & 0xFFFE)+1) * 37) være bedre? Hvor meget hjælper det og hvorfor?
  6. Hvilke tilgange, ressourcer osv. Vil du bruge til både at analysere algoritmen og designe en bedre?

Kommentarer

  • Dette er meget et XY-problem, som du beskriver det. En CSPRNG (bemærk S) virker ' t overhovedet ikke at være en god løsning. Nøglestørrelsesanmodningen er lidt underlig, hvorfor er det ikke muligt at bruge større nøglestørrelser?
  • Jeg formoder, at nøglestørrelsen ikke er vigtig. Jeg håbede, at 64 bit nøgle ville være nok til at kryptere en 32 bit værdi.

Svar

  1. Er der nogen eksisterende algoritmer, der fungerer i dette scenario?

Ja, faktisk , der er et antal 64 bit blokkoder. Standardvisdommen er, at de ikke opmuntres til generel brug, fordi standardblokcrypteringstilstande har tendens til at begynde at lække information, når du nærmer dig fødselsdagsbundet (i dette tilfælde ca. 30 Gbytes), men for din brugssag ville det ikke være en bekymring.

Her er nogle muligheder:

  • 3DES (aka TDES); dette er DES anvendt tre gange med tre forskellige taster; dette har fordelen for at være meget godt undersøgt.

  • Speck , som har parametersæt med 64 bit blokcifre. Dette har fordelen ved at være det hurtigste alternativ og blev designet af folk, der ved, at de laver og har gjort gennem en overraskende mængde kryptoanalyse.

  • En FPE-chiffer (såsom FF1, som kan håndtere enhver vilkårlig blokstørrelse (inklusive 64 bit). Dette har den fordel, at de giver mulighed for en tweak (som er et praktisk sted at placere de “andre skjulte parametre”, hvis du beslutter, at det er en fordel ). Det er langsommere end alternativerne; med FF1 kommer sikkerheden fra den underliggende sikkerhed i AES plus den påviselige sikkerhed i Feistel-strukturen.

Nu tager disse nøgler længere end 64 bit; den fælles visdom er, at en 64-bit nøgle bare ikke er lang nok.

  1. Hvor svært ville det være at knække? Det vil sige beregne værdier, der dekrypteres til gyldige indekser.

For et af ovenstående vil den eneste praktiske mulighed, som en modstander har, være at gæt tilfældigt ciphertexts og håber at snuble på en, der dekrypterer til et gyldigt indeks.

  1. Hvor meget koster besiddelse af flere prøver påvirker effektiviteten ved at revne det?

For et af ovenstående vil det at have store mængder prøver stadig gøre angrebet umuligt.

  1. Hvad er der galt med en naiv tilgang som …

ARX-chifre (faktisk enhver chiffer, men især ARX) er vanskelige at få ret. Specielt ARX-chifre har tendens til ikke at være gode til at afbryde differentierede og lineære egenskaber (hvilket betyder enhver sådan design skal virkelig studeres godt for at sikre, at det gør det).

  1. Hvilke tilgange, ressourcer osv. vil du bruge til både at analysere algoritmen og designe en bedre?

Jeg foreslår, at du går med et design, der allerede er analyseret. Jeg nævner tre ovenfor.

Kommentarer

  • Jeg ' foretrækker f.eks. Blowfish frem for 3DES, hvis der er en ændring af relativt lille nøgleindgang. Sikkerheden ved 3DES ville være i tvivl, selvom -tasten blev udvidet til 128 bit (eller rettere sagt 112 bit, selvfølgelig).
  • @MaartenBodewes: har du et citat af nogen, der viser, at 3DES med en ukendt nøgle, der kan skelnes fra en tilfældig jævn permutation?
  • Nej, selvfølgelig ikke. Men ' vil jeg hellere ikke engang have til grund, hvis min kryptering har ~ 80 bit eller ~ 112 bit styrke, når der tilføres en 128 bit eller 192 bit nøgle (I ' har vi ingen tvivl om, at du ville være i stand til at gøre det, men hej, vi re ikke alle poncho). Og nøglestørrelse ser ud til at være et problem i spørgsmålet. Bare at smide paritetsbitene i så fald er spild.
  • Kan du uddybe udsagnet " Nu tager disse nøgler længere end 64 bits; den fælles visdom er, at en 64 bit nøgle bare ikke er lang nok. "? Hvilke algoritmer kræver nøgler med hvilke længder, og 64bit nøgler er ikke lange nok til hvad, præcist?
  • @shader: nøgler på kun 64 bit er sårbare fra søgninger efter brute force fra store (velfinansierede) modstandere. Da det generelt er let nok at bruge noget større nøgler (f.eks. 128 bit), som ikke er ' t sårbare over for nogen, vælger vi generelt den mere sikre mulighed (selvom vi ' er ikke umiddelbart bekymret for, at NSA vil være interesseret i at angribe os, eller hvis Amazon beslutter at afsætte hele deres sky til os …

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *