oktober 28, 2020
Articles
Inga kommentarer

Hur krypterar man 64 bitars värden symmetriskt?

Jag är nyfiken på en algoritm som skulle vara bra för följande scenario:

  1. 32-bitars ”vanlig text” ingång, hämtad från en räknare
  2. 32 eller 64-bitars ”ciphertext” -utgång
  3. Det borde vara möjligt att dekryptera utdata med nyckeln (och eventuellt några andra dolda parametrar, som en förskjuten och aktuell räknare), och returnera det ursprungliga 32-bitars räknarvärdet
  4. En användare observerar aldrig ingången, men kan ta emot ett antal utgångar, eventuellt sekventiella. Ändå borde de inte kunna vet vilka index de har.
  5. Det borde vara svårt att gissa andra utgångar som motsvarar giltiga räknarvärden.

Min otränade intuition är att eftersom nyckeln och utgångarna är större än ingångsutrymmet borde det vara ganska enkelt att ha ”bra” resultat, åtminstone för de första utgångarna. Det verkar dock också logiskt att med tillräckligt med prover kan nyckeln och index lätt beräknas, men jag förväntar mig att de flesta fall att använda l ess än 100 värden.

Mina frågor är:

  1. Finns det några befintliga algoritmer som fungerar för detta scenario?
  2. Hur svårt skulle det vara att spricka? Det vill säga beräkna värden som dekrypteras till giltiga index.
  3. Hur mycket påverkar innehavet av fler prover effektiviteten i att knäcka det?

  4. Vad är det som är fel med en naiv strategi som: 

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

    Om man antar att tillägget slår runt 64-bitars heltalsgränser. Det verkar som om det helt blandar den slumpmässiga tangenten med en enda ingång, men har mer än en produktionen kan snabbt öka informationen som en angripare har, även om jag inte vet hur. Uppenbarligen kommer det att gå sönder, jag försöker bara lära mig.

  5. Skulle använda ett nyckelberoende värde för vänster rotation, som (((key & 0xFFFE)+1) * 37) vara bättre? Hur mycket hjälper det och varför?
  6. Vilka tillvägagångssätt, resurser etc. skulle du använda för att både analysera algoritmen och utforma en bättre?

Kommentarer

  • Detta är i hög grad ett XY-problem som du beskriver det. En CSPRNG (notera S) verkar inte ' t alls vara en bra lösning för detta. Nyckelstorleksbegäran är lite konstig, varför är det inte möjligt att använda större nyckelstorlekar?
  • Jag antar att nyckelstorleken inte är nödvändig. Jag hoppades att 64-bitars nyckel skulle räcka för att kryptera ett 32-bitarsvärde.

Svar

  1. Finns det några befintliga algoritmer som fungerar för detta scenario?

Ja, faktiskt , det finns ett antal 64-bitars blockkoder. Standardvisdomen är att de inte uppmuntras för allmän användning, eftersom standardblockkrypteringslägen tenderar att börja läcka information när du kommer nära födelsedagsbundet (i det här fallet cirka 30 Gbyte), men för ditt användningsfall skulle det inte vara ett problem.

Här är några alternativ:

  • 3DES (aka TDES); detta är DES tillämpas tre gånger med tre olika tangenter; detta har fördelen att vara mycket väl studerade.

  • Speck som har parametersatser med 64-bitars blockkodare. Detta har fördelen med att vara det snabbaste alternativet och designades av människor som vet att de gör och har gjort en överraskande mängd kryptanalys.

  • En FPE-chiffer (t.ex. FF1, som kan hantera alla godtyckliga blockstorlekar (inklusive 64 bitar). Detta har fördelen genom att de tillåter möjlighet till en tweak (vilket är ett bekvämt ställe att placera ”andra dolda parametrar” om du skulle bestämma att det är en fördel Det är långsammare än alternativen; med FF1 kommer säkerheten från den underliggande säkerheten för AES, plus den bevisbara säkerheten för Feistel-strukturen.

Nu tar dessa tangenter längre än 64 bitar; den vanliga visheten är att en 64-bitars nyckel inte är tillräckligt lång.

  1. Hur svårt skulle det vara att knäcka? Dvs beräkna värden som dekrypteras till giltiga index.

För något av ovanstående skulle det enda praktiska alternativet en motståndare skulle ha att gissa slumpmässigt chiffertexter och hoppas kunna snubbla på en som dekrypterar till ett giltigt index.

  1. Hur mycket kostar innehavet av fler prover påverkar effektiviteten i att knäcka det?

För något av ovanstående kommer att ha stora mängder prover fortfarande att göra attacken omöjlig.

  1. Vad är fel med en naiv strategi som …

ARX-chiffer (faktiskt vilken chiffer som helst, men särskilt ARX) är svårt att få rätt. Speciellt ARX-chiffer tenderar inte att vara bra för att störa differentiella och linjära egenskaper (vilket betyder alla sådana design skulle verkligen behöva studeras väl för att se till att det gör det).

  1. Vilka tillvägagångssätt, resurser etc. skulle du använda för att både analysera algoritmen och utforma en bättre?

Jag föreslår att du går med en design som redan har analyserats. Jag listar tre ovan.

Kommentarer

  • Jag ' föredrar t.ex. Blowfish framför 3DES om det sker en förändring av relativt liten tangentinmatning. Säkerheten för 3DES skulle vara tveksam även om -tangenten utvidgades till 128 bitar (eller snarare 112 bitar, naturligtvis).
  • @MaartenBodewes: har du en citat av någon som visar att 3DES med en okänd nyckel som kan särskiljas från en slumpmässig jämn permutation?
  • Nej, naturligtvis inte. Men jag ' vill hellre inte ens resonera om min kryptering har ~ 80 bitar eller ~ 112 bitars styrka vid matning av en 128 bitars eller 192 bitars nyckel (jag ' har inte tvivlat på att du skulle kunna göra det, men hej, vi re inte alla poncho). Och nyckelstorlek verkar vara ett problem i frågan. Att bara kasta bort paritetsbitarna i så fall är slösande.
  • Kan du utarbeta uttalandet " Nu tar dessa nycklar längre än 64 bitar; den vanliga visdomen är att en 64-bitars nyckel inte är tillräckligt lång. "? Vilka algoritmer kräver nycklar av vilka längder, och 64 bitars nycklar är inte tillräckligt långa för vad, exakt?
  • @shader: tangenter på bara 64 bitar är sårbara från brute force-sökningar från stora (välfinansierade) motståndare. Eftersom det i allmänhet är tillräckligt enkelt att använda något större nycklar (t.ex. 128 bitar) som inte är ' t sårbara för någon, väljer vi i allmänhet det säkrare alternativet (även om vi ' är inte omedelbart oroliga för att NSA kommer att vara intresserade av att attackera oss, eller om Amazon bestämmer sig för att ägna hela sitt moln till oss …

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *