Sono curioso di sapere un algoritmo che sarebbe valido per il seguente scenario:
- “testo in chiaro” a 32 bit input, preso da un contatore
- output “ciphertext” a 32 o 64 bit
- Dovrebbe essere possibile decifrare loutput con la chiave (e possibilmente alcuni altri parametri nascosti, come un offset e un contatore corrente) e restituisce il valore originale del contatore a 32 bit
- Un utente non osserva mai linput, ma può ricevere un numero qualsiasi di uscite, possibilmente sequenziali. Anche così, non dovrebbero essere in grado di sapere quali indici hanno.
- Dovrebbe essere difficile indovinare altri output che corrispondono a valori di contatore validi.
La mia intuizione inesperta è che, poiché la chiave e gli output sono più grande dello spazio di input, dovrebbe essere abbastanza facile avere risultati “buoni”, almeno per i primi output. Tuttavia, sembra anche logico che con un numero sufficiente di campioni la chiave e gli indici possano essere calcolati facilmente, ma mi aspetto che la maggior parte dei casi usare l ess di 100 valori.
Le mie domande sono:
- Esistono algoritmi esistenti che funzionano per questo scenario?
- Quanto sarebbe difficile crepa? Vale a dire, calcola valori che decifrano in indici validi.
- Quanto il possesso di più campioni influisce sullefficienza del cracking?
-
Cosa cè di sbagliato in un approccio ingenuo come:
u64 output = input repeat 64x output = ((output ^ key) + key) rotate-left 37Supponendo che laddizione avvolga i confini di interi a 64 bit. Sembra che mescolerebbe completamente la chiave casuale con un singolo input, ma possedendo più di uno loutput potrebbe aumentare rapidamente le informazioni che un utente malintenzionato possiede, anche se non saprei come. Ovviamente non funzionerà, sto solo cercando di imparare.
- Userei un valore dipendente dalla chiave per la rotazione a sinistra, come
(((key & 0xFFFE)+1) * 37)essere migliore? Quanto aiuta e perché? - Quali approcci, risorse, ecc. Usereste per analizzare lalgoritmo e progettarne uno migliore?
Commenti
- Questo è un problema XY nel modo in cui lo descrivi. Un CSPRNG (nota la S) non ' sembra essere una buona soluzione per questo. La richiesta della dimensione della chiave è un po strana, perché non è possibile utilizzare chiavi di dimensioni maggiori?
- Suppongo che la dimensione della chiave non sia essenziale. Speravo che la chiave a 64 bit sarebbe stata sufficiente per crittografare un valore a 32 bit.
Risposta
- Esistono algoritmi esistenti che funzionano per questo scenario?
Sì, effettivamente , sono disponibili numerose crittografie a blocchi a 64 bit. La saggezza standard è che non sono incoraggiate per luso generale, perché le modalità di cifratura a blocchi standard tendono a far trapelare informazioni quando ti avvicini al limite del compleanno (in questo caso, circa 30 Gbyte); tuttavia per il tuo caso duso, ciò non lo farebbe essere un problema.
Ecco alcune opzioni:
-
3DES (aka TDES); questo è DES applicato tre volte con tre chiavi diverse; questo ha il vantaggio di essere molto ben studiato.
-
Speck che ha set di parametri con cifrature a blocchi a 64 bit. Questo ha il vantaggio di essere lalternativa più veloce, ed è stato progettato da persone che sanno che stanno “facendo, e hanno fatto attraverso una quantità sorprendente di crittoanalisi.
-
Un codice FPE (come FF1, che può gestire qualsiasi dimensione di blocco arbitraria (inclusi 64 bit). Questo ha il vantaggio di consentire lopzione per un tweak (che è un posto conveniente per posizionare gli “altri parametri nascosti”, se decidi che è un vantaggio ). Suo più lento delle alternative; con FF1, la sicurezza proviene dalla sicurezza sottostante di AES, più la sicurezza dimostrabile della struttura Feistel.
Ora, questi accettano chiavi più lunghe di 64 bit; la saggezza comune è che una chiave a 64 bit non è abbastanza lunga.
- Quanto sarebbe difficile decifrare? Vale a dire, calcola i valori che decrittano in indici validi.
Per uno qualsiasi dei precedenti, lunica opzione pratica che un avversario avrebbe sarebbe quella di indovinare a caso i testi cifrati e sperare di imbattersi in uno che decifra in un indice valido.
- Quanto costa il possesso di più campioni influiscono sullefficienza del cracking?
Per uno qualsiasi dei precedenti, avere grandi quantità di campioni renderà ancora impossibile lattacco.
- Cosa cè di sbagliato in un approccio ingenuo come …
I cifrari ARX (in realtà, qualsiasi cifrario, ma specialmente ARX) sono difficili da correggere. I cifrari ARX in particolare tendono a non essere ottimi per interrompere le caratteristiche differenziali e lineari (il che significa il design avrebbe davvero bisogno di essere ben studiato per assicurarsi che lo faccia).
- Quali approcci, risorse, ecc. usereste per analizzare lalgoritmo e progettarne uno migliore?
Suggerirei di andare con un design che è già stato analizzato; ne elenco tre sopra.
Commenti
- I ' preferirei, ad esempio, Blowfish a 3DES se ci fosse un cambiamento di input chiave relativamente piccolo. La sicurezza di 3DES lo dubitare anche se la chiave è stata espansa a 128 bit (o piuttosto 112 bit, ovviamente).
- @MaartenBodewes: hai una citazione di qualcuno che mostra che 3DES con un la chiave sconosciuta è distinguibile da una permutazione uniforme casuale?
- No, ovviamente no. Tuttavia, ' preferirei non dover nemmeno ragionare se la mia crittografia ha ~ 80 bit o ~ 112 bit con una chiave a 128 bit o 192 bit (I ' non ho dubbi che saresti in grado di farlo, ma hey, noi non sono tutti i poncho). E la dimensione della chiave sembra essere un problema nella domanda. In questo caso, buttare via i bit di parità è uno spreco.
- Potresti approfondire listruzione " Ora, questi accettano chiavi più lunghe di 64 bit; la saggezza comune è che una chiave a 64 bit non è abbastanza lunga. "? Quali algoritmi richiedono chiavi di quali lunghezze, e le chiavi a 64 bit non sono abbastanza lunghe per cosa, precisamente?
- @shader: le chiavi di soli 64 bit sono vulnerabili dalle ricerche di forza bruta da grandi avversari (ben finanziati). Poiché generalmente è abbastanza facile usare chiavi un po più grandi (ad es. 128 bit) che non sono ' t vulnerabili a chiunque, generalmente optiamo per lopzione più sicura (anche se ' non è immediatamente preoccupato che la NSA sia interessata ad attaccarci, o se Amazon deciderà di dedicarci tutto il suo cloud …