Come utilizzare al meglio JavaScript per crittografare il lato client in modo che il server non lo veda mai?

JavaScript crypto è generalmente considerato una cattiva idea (vedi i dettagli qui )

Se stai cercando di affrontare la minaccia del server malevolo, allora il primo problema che si incontra è "da dove viene il codice JavaScript da cui proviene la crittografia"?

La solita risposta per i siti web è, "viene dal server", che ti lascia il problema che se il server è malvagio possono semplicemente cambiare il codice JavaScript per dare loro una copia della chiave richiesta per decodificare i dati.

Ciò rende JavaScript il tipo criptato di inutile ...

Le recenti perdite della CIA (e in misura minore, le rivelazioni di Snowden precedenti) mi hanno convinto che @ rоry-mccune's answer (che in precedenza credevo anch'io) non è più un buon consiglio. I documenti della CIA affermano che gli attacchi di downgrade del protocollo rendono inefficiente HTTPS. Inoltre è del tutto possibile che anche se una parte ha un server chiavi private (abilitando entrambe le modifiche E di sorveglianza HTTPS) non può rischiare di rivelare di avere le chiavi private alterando il contenuto tramite un Attacco MITM, dal momento che il contenuto modificato potrebbe essere rilevato. Si noti inoltre che la sorveglianza passiva può portare a un compromesso attivo. Ad esempio, se una password o un token di accesso viene inviato al server, un utente malintenzionato può utilizzare tale password per ottenere un ulteriore accesso senza dare per scontato che ha infranto una cifra o implementato un attacco passivo di downgrade del protocollo (passivo perché è solo ricognizione (non alterazione / forgiatura) - presumibilmente in una rete o come parte di una botnet di router hacker / punti wifi).

Inoltre, la generazione di un lato client della chiave privata, l'invio della chiave pubblica insieme al messaggio crittografato e l'eliminazione (o la sostituzione periodica) del lato client della chiave privata garantiscono un maggiore grado di segretezza in caso di violazione della cifra.

Oltre alle possibili prestazioni in determinati contesti, non riesco a vedere il lato negativo della crittografia lato client. Sì CSP, HSTS precaricato e HPKP, TLS 1.2+ sono più importanti e sì, se stai caricando il codice da un'altra parte puoi scopare con il tuo runtime e sì il generatore di numeri casuali potrebbe non essere abbastanza puro ma l'intero argomento è imperniato su questa citazione dall'articolo collegato:

You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. Meanwhile, the Javascript crypto code is still imperiled by other browser problems.

Che la CIA dice non è vero nei documenti classificati trapelati.

Inoltre, le perdite di Snowden hanno mostrato come in molti casi i governi usassero reti pigre per la maggior parte dei siti e attacchi mirati per alcuni (come Google) che erano abbastanza sicuri da causare problemi. Se un cifrario viene infranto in modo segreto, sarà meglio protetto implementando ciò che in caso contrario.

Per quanto riguarda cosa consigliare specificamente, non ho avuto il tempo di esaminare le alternative. L'autore dell'articolo collegato menziona questo ma ora che abbiamo quello che sta cercando di essere un generatore di numeri casuali sicuro in Chrome e Firefox I Pensa nel complesso che stiamo meglio cercando di incoraggiare più sviluppatori open source a proteggere le cose piuttosto che non provare a farlo. Assicurati solo che sappiano che è importante avere ancora TLS.