Crittografia JavaScript per siti Web distribuiti tramite IPFS

Bene, un problema fino a poco tempo fa (cioè la scorsa settimana!) era che le implementazioni di Math.random () nella maggior parte dei browser erano, francamente, spazzatura. Entrambi V8 (il motore Javascript dietro a Chrome e NodeJS) e < a href="http://jandemooij.nl/blog/2015/11/30/testing-math-random-crolking-the-browser/"> Spidermonkey (il motore di Firefox) ha utilizzato PRNG con periodi troppo brevi e ci sono prove che suggeriscono che anche IE e Edge hanno rotto i PRNG. Ciò significa che se ci sono chiamate da qualsiasi cosa in un livello che si basa su di loro, ci sarà un insieme limitato di risultati possibili. Ora, questo può ancora essere un sacco di risultati (circa 590 milioni, per il caso V8), ma questo è molto meno del 2 ^ 132 ideale (5.444.517,870,735,015,415,413,993,718,908,291,383,296).

Ciò significa che qualsiasi attacco ha una probabilità molto più alta di successo: intercettare i dati in transito e quindi attaccare offline. Potrebbe richiedere un po 'di tempo, ma AES è veloce sui processori moderni e i computer sono economici.

Altri problemi con questo potrebbero essere: come si può garantire che non ci siano estensioni in uso? Il browser è fuori dal tuo controllo. Come puoi essere sicuro che non ci siano difetti nascosti in IPFS? I professionisti della sicurezza tendono a preferire i sistemi che sono stati soggetti a molti attacchi, e non sono stati rotti, a nuovi sistemi che non sono stati testati tanto. Anche se la teoria matematica è perfettamente valida, l'implementazione è corretta? Un errore di battitura o un'aggiunta errata potrebbe causare un grosso problema: vedi Heartbleed.

Ci sono anche problemi con altre parti dell'infrastruttura del browser che possono influenzare alcuni tipi di crittografia nel browser. L'interfaccia di FileWriter era deprecata, il che significa che qualsiasi cosa più grande della memoria del browser non può essere decifrata in modo affidabile (non esiste un modo ragionevole di scriverlo su disco - stranamente, FileReader funziona bene per la crittografia). Manca il supporto del browser per le operazioni di crittografia: Windows e Linux possono utilizzare chiamate native per AES al giorno d'oggi, su processori moderni, ma ci vorrebbe del lavoro per rendere i browser in grado di fare lo stesso.

Ci stiamo arrivando, ma non è ancora un problema risolto. Se IPFS resiste al controllo, i produttori di browser implementano fonti di randomizzazione migliorate, e così via, sarà vicino. Il problema dell'estensione non sembra destinato a scomparire - le persone sembrano attaccate ai loro adblockers, e probabilmente non vogliono scambiare la sicurezza non avendo abilitate le estensioni per gli annunci pubblicitari!

Ci sono molti trabocchetti , quando si fa cripto in JavaScript. Ti consiglio di consultare l'API WebCrypto , poiché fornisce le primitive crittografiche che ti consentono di utilizzare la crittografia moderna.

Ti consiglio di consultare la presentazione di Tim Taubert sull'API WebCrypto mentre ti guida attraverso le note app che memorizza il contenuto crittografato. Al suo termine, consiglia di derivare una chiave di crittografia tramite PBKDF2 e crittografia utilizzando AES-GCM.

I tuoi restanti problemi sono probabilmente:

• Denial of service: puoi fidarti del provider di archiviazione di non rimuovere dati o parti dei dati?
• Prestazioni: se tutti i dati dell'utente sono un unico blog crittografato, sarà necessario crittografare nuovamente tutto anche con modifiche minime.

È possibile contrastare il problema delle prestazioni crittografando gli elementi in un array in modo selettivo, ma ciò porterà ulteriori considerazioni sulla sicurezza: è necessario evitare il riutilizzo nonce e archiviare gli effetti per elemento. Un provider di archiviazione non attendibile può ancora eliminare le righe, a meno che non crei un albero di hash per verificare in profondità l'integrità dei dati.

potrebbe consentire anche modifiche di password con una "chiave di crittografia chiave" (ad esempio generare chiave di archiviazione casuale per la crittografia, crittografare questa chiave di archiviazione con la chiave di crittografia della chiave derivata dalla password).

Come vedi, la crittografia di per sé non è una panacea. Devi trovare una grande quantità di ingegneria della crittografia solida in cima.

Non farlo. IPFS non è sicuro. Qualcuno tra l'utente e il nodo IPFS potrebbe decidere di intercettare e modificare le query. C'è anche il problema che qualcuno potrebbe cambiare i file localmente in IPFS. Chiunque ottenga i propri file da quell'host riceverà codice dannoso. Qualcuno potrebbe scrivere un virus che modifica il contenuto dei file non appena arrivano sul computer degli utenti .

Anche se supponiamo che IPFS sia perfettamente sicuro, lo scripting cross-site è un vero problema. È stato fatto in vari modi e tutto ciò che un utente malintenzionato deve fare per superare la crittografia è cambiare una funzione su cui fai affidamento.

Tutto ciò che un utente malintenzionato XSS deve fare è ottenere una singola riga di codice da eseguire:

Math.random = function () {return 0.4;};

e l'intera crittografia probabilmente cade senza che nessuno se ne accorga. Peggio ancora, i dati dell'utente verranno archiviati in modo non sicuro su IPFS, aperti per chiunque conosca le tue funzioni (chiunque abbia accesso a IPFS) e il seme casuale da leggere.

Ci sono un sacco di altri modi per infrangere la tua crittografia se lo fai nei browser. Per ulteriori informazioni, controlla la pagina che hai collegato: puoi escludere pochissimi punti fatti lì. Se non capisci perché sono ancora validi, dovresti passare un po 'di tempo a leggere su networking / crittografia.

Se si desidera creare un sistema distribuito in IPFS con dati crittografati, disporre di un server di autenticazione centralizzato per il backup e utilizzare quel server per tutto ciò che è necessario in termini di crittografia.