Quanto sono sicuri i file HTML auto-decodificanti per l'archiviazione dei dati?

Almeno l'autore ha scritto una pagina piuttosto chiara su come funziona la sua crittografia . Ciò nonostante, sembra un codice stream casalingo piuttosto vecchio stile, che non è una buona notizia, dal momento che molti di questi sistemi sono stati completamente infranti. Sembra costituito da un sottosistema LFSR di base (due LFSR con polinomi dipendenti dalla chiave, il bit relativo ai polinomi che operano in "direzione inversa" è un'aringa rossa, poiché questo sottosistema è ancora interamente lineare) e un altro LFSR che funge da non motore di selezione lineare. Ci sono alcuni progetti selezionati che hanno approssimativamente lo stesso aspetto e sembrano offrire una resistenza criptoanalitica non trascurabile (ad esempio il Alternate Step Generator ), ma questo ha un prezzo, vale a dire che hai bisogno di molto più di n bit di stato interni se vuoi ottenere 2 ⁿ livello di sicurezza. Inoltre, molti di questi progetti si sono rivelati deboli.

Ci si può fidare della resistenza di un algoritmo crittografico basato sulla combinazione delle seguenti proprietà:

• Il designer è noto per essere molto bravo nel progettare algoritmi (ad esempio il suo nome è Rivest ).
• Il design ha ottenuto un'ampia visibilità, ad esempio è stato pubblicato in alcune conferenze di alto profilo e / o è stato distribuito su larga scala.
• Sono trascorsi diversi anni e nessuno ha riscontrato alcun problema.

Questo design è un po 'carente sui tre punti.

Modifica: non l'avevo notato (ho bisogno di più caffè al mattino) ma lo stream generato è deterministico per una determinata password. Ciò significa che se crittografa due archivi con la stessa password, sei nella famigerata situazione "due tempi di pad", e in pratica hai perso.

Un altro punto è che la password è derivata in una chiave con solo una coppia di invocazioni di MD5. MD5 è molto veloce; una GPU buona, ma già disponibile e non del tutto dispendiosa può valutare MD5 ad una velocità di circa un miliardo al secondo. Se i primi byte dei dati crittografati vengono indovinati dall'attaccante (poiché si suppone che il testo in chiaro sia Javascript, i primi byte sono probabilmente " var " o " function "), quindi l'intera cosa è vulnerabile a attacchi di dizionario , ovvero "ricerca esauriente sulla password" (provare le potenziali password finché non viene trovata una corrispondenza). È è possibile avere una grossa password casuale che sconfigge gli attacchi del dizionario e un cervello umano potrebbe ancora ricordarlo con un certo sforzo. Ma la maggior parte delle password sono deboli sotto questo aspetto. Inoltre, niente sale: per una determinata password, ottieni sempre lo stesso flusso. Pertanto, è possibile precomputare i primi byte del flusso per ogni potenziale password, e in seguito il cracking di qualsiasi istanza sarebbe una questione di poche ricerche nella tabella (la tabella potrebbe assumere la forma di un tavolo di curve per una memoria più compatta).

Per la parte relativa alla gestione delle password, questo schema è decisamente debole.

Anche il caso d'uso è dubbio. Poiché questo è il codice Javascript in cui l'utente inserisce la sua password, questo è vulnerabile agli attacchi attivi: un utente malintenzionato può semplicemente modificare il codice Javascript, in modo che quando l'utente immette la sua password, una copia della password viene registrata anche da qualche parte (ad es. i dati decrittografati, che dovrebbe essere JavaScript in sé, ricevono uno snippet di codice aggiuntivo che stampa un tag <img> nascosto con un URL che punta a un server controllato da un utente malintenzionato e codifica la password).

Per sconfiggere attacchi attivi di questo tipo, la soluzione è nota, e questo è SSL. L'archivio "auto-decrittante" deve essere pubblicato solo su HTTPS. Ma se viene utilizzato HTTPS, perché è necessaria l'auto-decodifica? Invece, chiedi al server di dare il pezzo sensibile di Javascript solo dopo aver autenticato l'utente, con la password. Questo è un modello molto comune, i server Web esistenti lo implementano immediatamente, ed è più potente dal momento che ostacola gli attacchi del dizionario offline (dall'esterno, l'attaccante non può "provare le password" alla massima velocità della sua GPU; chiedi al server ogni ipotesi e il server può rispondere il più lentamente possibile.

Riepilogo: ti consiglio di contro di utilizzare questo pezzo di codice. Continuo a notare che, almeno, il progettista di SDA sembra aver compiuto sforzi lodevoli per la documentazione, e che essere sano di mente lo mette in minoranza, tra la folla di designer di cifrari su Internet.

Il problema con tutti questi tipi di cose è che non puoi davvero stabilire quanto siano sicuri. Quello che facciamo invece è una certa fiducia in quelli che sono stati testati nel tempo da un gran numero di persone esperte (@ThomasPornin ha una risposta eccellente su questo, che cercherò di trovare un link a) - questo è probabilmente il motivo per cui l'autore ha posto la sfida: lo vuole testato.

Questo può usare un algoritmo sicuro, ma se l'implementazione presenta dei punti deboli, potrebbe essere insicuro.

In sintesi: se hai un reale bisogno di un SDA sicuro, ti suggerirei di provarlo con uno collaudato, poiché il rischio è probabilmente inferiore. Se tuttavia riesci a rivedere il codice che sta dietro a questo e a valutare il rischio che i tuoi usi siano sufficientemente bassi, allora questo potrebbe andar bene per i tuoi scopi.

(Mi spiace che sia un po 'incerto, ma molto di questo è ...)

Io generale starei lontano da qualsiasi cosa in cui non è possibile rivedere il codice e devi fare la crittografia online. Forse non è questo il caso, ma ogni volta in passato ho visto nuovi algoritmi di crittografia o steganografia che erano disponibili solo online, era un honeypot che raccoglieva dati su ciò che le persone là fuori potevano voler criptare / nascondere.