Idea per un'applicazione NON-web cancellata crittografata

Question

Idea per un'applicazione NON-web cancellata crittografata

#1 da (3 voti)
#2 da (2 voti)

5

Ho un'idea per un'app che potrebbe essere utile (anche se non lo è, ho comunque imparato nel processo, che è ciò che conta).

Ci sono un sacco di applicazioni web pastebin crittografate disponibili (ad esempio defuse.ca/pastebin.htm) che eseguono la crittografia / decrittografia sul client utilizzando JavaScript. Quindi, la crittografia end-to-end viene raggiunta, A MENO CHE un utente abbia hackerato il server e modificato il codice JavaScript in modo che i futuri utenti che si connettono ottengano il codice JavaScript modificato che rimanda la password non crittografata all'hacker.

La mia idea è che l'utente debba interagire con un'app client autonoma anziché con un'app browser per rimuovere la vulnerabilità JavaScript.

L'utente scarica l'app standalone del client. Durante il download / l'installazione viene fornita una certa sicurezza perché: un. L'app client è firmata digitalmente b. I download avvengono da un server https c. Gli hash SHA sono disponibili per i file scaricati d. Il codice sorgente per l'app client è disponibile
L'utente avvia l'app e seleziona "new paste". Vede una grande casella di testo.
Tipi di utenti / paste testo e clic "Invia". All'utente viene richiesta una password e la inserisce.
L'app client CSPRNG genera sale S di 128 bit
La funzione di derivazione lenta accetta password e S e deriva la chiave a 256 bit K e il vettore di inizializzazione a 128 bit IV.
Esegui crittografia Aes (dimensione del blocco a 128 bit, chiave a 256 bit, modalità CBC, riempimento PKCS7) utilizzando testo in chiaro, K e IV per produrre Cyphertext C.
Server delle app delle app client (chiamata di resto a https uri), passando S e C
Il server memorizza S e C in una riga del database (S è chiave primaria).
Server indica al client che i dati sono archiviati. Il client dice all'utente "dati salvati" e presenta S all'utente come identificatore di incolla univoco.
L'utente prende nota di S (file di testo sul suo computer, e-mail a se stesso, ecc ... non deve essere tenuto segreto). La password deve essere tenuta segreta.
Successivamente, l'utente avvia nuovamente l'app client.
Sceglie "apri pasta esistente". Inserisce S e seleziona trova.
L'app del client chiede al server di trovare una corrispondenza di corrispondenza S (chiamata di resto a https uri). Se lo fa, restituisce il testo crittografato.
Se si trova incollare, l'app client richiede all'utente la password di decrittografia. Lo digita.
La funzione di derivazione lenta accetta password e S e deriva la chiave a 256 bit K e il vettore di inizializzazione a 128 bit IV.
Decodifica Aes eseguita (dimensione del blocco a 128 bit, chiave a 256 bit, modalità CBC, riempimento PKCS7) utilizzando testo in chiaro, K e IV per produrre plainText.
L'app client mette il testo in chiaro nella casella. L'utente può modificarlo e ricodificarlo o chiuderlo e creare una nuova incolla (torna al passaggio 2).

Note:

Diversi utenti potrebbero visualizzare la stessa pasta se: un. Sono d'accordo in anticipo su una password o la password viene comunicata dall'utente 1 all'utente 2 dopo aver fatto una copia, AND b. L'utente che fa la pasta condivide S con altri utenti (questo può essere condiviso in modo non sicuro).

Domande:

Quali vulnerabilità di sicurezza ha questa installazione e come potrebbe essere migliorata?
Mi manca qualcosa di vitale in termini di esperienza utente?
Ri: Passaggio 17. Ho letto che non si dovrebbe mai usare lo stesso sale due volte. Sarebbe fastidioso che l'identificatore della pasta (S) cambi con ogni modifica / reencryption (se più utenti accedono alla stessa pasta, avrebbero bisogno di consigliare la nuova S ogni volta che viene effettuato un aggiornamento / reencryption), ma è inevitabile farlo se non voglio sacrificare la sicurezza?

Grazie in anticipo!

encryption hash

posta Ralph P 07.04.2016 - 21:42

fonte

2 risposte

Leggi altre domande sui tag encryption hash

Come decifrare il traffico SSL con uno sniffer di pacchetti quando ho la chiave privata? Come faccio a schematizzare un nodo di rete con più livelli di attendibilità?

score 3 · Answer 1

Sono un membro della polizia mentale in uno stato di polizia distopico e posso intercettare tutto il traffico Internet.

Attraverso il mio lavoro investigativo ho scoperto che Bob è un criminale pensante. Ma Bob è fuori dalla mia portata.
Ho notato che Bob ha usato il tuo programma per caricare diversi cyphertexts con i sali S1, S2 e S3 sul tuo server.
Ho anche notato che Alice, Charlie e Dora hanno richiesto i cyphertexts con i sali S1, S2 e S3 dal tuo server.

So qual è il contenuto di questi messaggi? Non ancora, ma quando li trattengo tutti e tre e li interrogo per un po ', allora uno di loro sicuramente si spezzerà. Mi interessa anche? In realtà, io no. L'associazione con Bob è una ragione sufficiente per condannarli per tradimento.

Come potresti rendere più difficile il mio lavoro?

Utilizza TLS con inoltro segreto per la comunicazione tra server e client. In questo modo, so solo chi usa il tuo servizio e quando, ma non quale messaggio sono esattamente caricati / scaricati. Quando il numero di file non onerosi è molto più grande del numero di file "treasonous", arrestare tutti gli utenti nel caso fosse irrealizzabile (abbiamo solo così tante stanze per gli interrogatori e la nostra economia non può permettersi di chiudere troppi del nostro lavoro droni contemporaneamente). Avvertenza: quando riesco a sequestrare il tuo server, riesco a intercettare nuovamente i tuoi utenti.

Potresti anche chiedere al tuo cliente di richiedere un sacco di file casuali (ma validi) che l'utente non ha richiesto e per i quali non ha nemmeno la password. In questo modo puoi offuscare la rete di comunicazione dei tuoi utenti e costringermi a perdere tempo con la detenzione di un sacco di persone a caso che non sanno nulla.

Ma se vuoi veramente darmi mal di testa, sbarazzati del tuo server centrale e passa a un'architettura distribuita come Freenet dove tutti i dati sono distribuiti sulla rete client e nessuno sa quale client detiene quali documenti (nemmeno i client stessi). Ma una modifica così drastica dell'architettura ti rimanderebbe al tavolo da disegno per ridisegnare il tuo protocollo da zero.

score 2 · Answer 2

Sembra che il link più debole sia la password poiché questa è l'unica cosa necessaria per decodificare il testo, quindi gli utenti DEVONO creare buone password. Non riesco a parlare con la maggior parte delle decisioni di sicurezza che hai scelto, ma ho alcune opinioni sull'interfaccia utente:

C'è un potenziale rischio di collisione di S . Perché non fare in modo che l'app client interroghi il server per S come parte del passaggio 2 e il server restituisca un ID univoco. Alcuni (molti) di questi ID potrebbero non essere mai usati (se il Passo 7 non viene completato, inviando C al server) ma va bene.
Potresti includere una stringa magica (ad esempio, il nome della tua app) come prefisso del testo in chiaro prima della crittografia. L'utente non lo vedrebbe, ma quando la decifrazione avviene la tua app può verificare l'esistenza della stringa magica e se non c'è, segnala un avviso all'utente. Questo sarebbe più user-friendly rispetto a mostrare caratteri garbage da una decifrazione fallita.
Va bene riutilizzare il sale un paio di volte, vuoi solo che generalmente sia diverso per impedire a un utente malintenzionato di utilizzare una tabella arcobaleno per "invertire" un hash. L'unica possibilità di riutilizzare il sale entrerebbe in gioco se l'utente continuava a cambiare la password da un set limitato (ad esempio un PIN numerico a 4 cifre) e un utente malintenzionato ha avuto l'opportunità di costruire un tavolo arcobaleno o se l'attaccante già aveva una tabella arcobaleno creata con quel sale (quindi usa qualcosa di simile a un UUID (probabilmente l'utente sta inviando il link via email, quindi non importa se S è molto lungo; se ha bisogno di per abbreviare potresti anche aggiungere una funzionalità di abbreviazione dell'URL che punta solo a S )).