Crittografia file per un'API di archiviazione

Question

Crittografia file per un'API di archiviazione

#1 da (2 voti)
#2 da (0 voti)

1

Sto implementando un'API di tipo Dropbox e uno dei miei requisiti è quello di avere i file memorizzati crittografati sul server. È non richiesto che i file siano resi illeggibili dal server, solo che non sono archiviati in chiaro su disco. Sto usando Python con Flask per la parte API e PyCrypto per la crittografia.

Non conosco assolutamente nulla di crypto e non voglio fare nulla (troppo) stupido. Questo è ciò che ho implementato, per favore dimmi come suona [un] ragionevole:

Quando l'utente immette un file, il contenuto viene crittografato mentre viene letto dalla rete utilizzando AES-256 MODE_CTR (Volevo evitare la restrizione della dimensione del blocco di MODE_ECB e MODE_CBC)
La chiave di crittografia è la password con hash dell'utente: evita di utilizzare una singola "chiave server" per ogni file memorizzato e rende i file illeggibili se l'utente cambia la password
La generazione di contatori utilizza Crypto.Util.Counter con un parametro casuale initial_value specifico per ogni file e memorizzato nel database (proprio come una password salt)
Sto prendendo in considerazione l'estensione dell'API per consentire all'utente di fornire la propria chiave di crittografia insieme alla richiesta PUT. Dovrebbe quindi fornire la stessa chiave nel suo GET per recuperare il contenuto decifrato.

Ovviamente, la comunicazione con l'API avviene su HTTPS.

python aes file-encryption pycrypto

posta ThemCrookedVultures 17.03.2014 - 15:26

fonte

2 risposte

Leggi altre domande sui tag python aes file-encryption pycrypto

Come limitare la necessità di digitare una passphrase master lunga solo una volta per sessione di accesso? L'aumento dell'ID di sessione tomcat aumenta la sicurezza

score 2 · Answer 1

Molto irragionevole.

La prima domanda che penso sia necessario è se la crittografia dei file è necessaria. In base alla tua domanda sembra che la risposta sia sì. Per me questo significa che A) dovrebbe implementare la crittografia dei file e B) farlo bene. Quello che descrivi è A ma non B, che è probabilmente peggio di niente perché potrebbe dare ai tuoi utenti un falso senso di sicurezza.

Ecco le mie preoccupazioni (come ingegnere e potenziale utente del tuo prodotto):

"Non conosco assolutamente nulla di crypto" - Crypto è facile da sbagliare e difficile da correggere, perché vorresti che fosse implementato da qualcuno che, per sua stessa ammissione, non sa nulla di cripto? Pensa ai prodotti su cui fai affidamento come cliente, se la loro sicurezza è stata implementata da qualcuno che non sapeva nulla sulla sicurezza, ti darebbe sicurezza?

"La chiave di crittografia è la password con hash dell'utente" - Generare una chiave simmetrica casuale e univoca per file è facile. Ogni volta che è necessario memorizzare un file, creare una nuova chiave e crittografarla con qualcosa che solo il proprietario del file sa (la password potrebbe non essere una cattiva scelta). Perché vuoi che tutti i file diventino irrecuperabili quando cambiano la loro password?

"consente all'utente di fornire la propria chiave di crittografia" - Questa è in realtà un'idea eccellente e qualcosa che Amazon S3 ha appena introdotto. Consenti agli utenti di fornire file crittografati o file di testo in chiaro insieme a una chiave di crittografia. I server assumono il lavoro di crittografia ma l'utente ottiene il controllo. Assicurati di aver rimosso la chiave di crittografia dopo averla utilizzata, non lasciarla in memoria o nei file di registro.

score 0 · Answer 2

Un paio di puntatori

Quando usi la crittografia simmetrica puramente, avrai problemi con concetti come la crittografia a chiavi multiple, l'impegno, ecc. Potresti considerare l'utilizzo di PGP invece.
Idealmente, ogni sessione / file avrebbe una propria chiave simmetrica casuale, quando si utilizza la password utente con hash, si perde su questo. PGP risolverebbe questo per te. Quando decidi di utilizzare una password utente, assicurati di utilizzare un algoritmo di hash strong come PBKDF2 con un MAC da generare la chiave di crittografia dalla password fornita.
Assicurati di utilizzare un PRNG sicuro per inizializzare il codice. Per quanto ne so, la modalità CTR è considerata valida (non sono un crittografo, però)
La condivisione del segreto è molto meno sicura rispetto all'utilizzo di chiavi asimmetriche, nel qual caso l'utente può condividere liberamente la sua chiave di crittografia (pubblica), mantenendo la chiave segreta effettivamente segreta. Di nuovo, questo è fatto facilmente con PGP.