Crittografia con password - Crittografia di chiave contro dati

Il vantaggio principale dell'utilizzo di una chiave intermedia è che consente di modificare la password senza rielaborare tutti i dati.

es. hai un grosso file (gigabyte ...) cifrato con la chiave casuale K (un valore di 128 bit), e K è esso stesso crittografato con P (la chiave derivata dalla password). Se cambi la tua password, ottieni una nuova chiave derivata da password P '. Per regolare le cose, devi quindi decrittografare K con P e ricodificarlo con P '. Questo non richiede la ricodifica o l'accesso al grande file.

Oltre a questo vantaggio, l'utilizzo di una chiave intermedia disaccoppia l'operazione, che è più flessibile. Ad esempio, il processo utilizzato per trasformare la password in una chiave simmetrica potrebbe non essere all'altezza del compito di produrre una chiave della lunghezza desiderata per la crittografia di massa (ad esempio, bcrypt produrrà una chiave a 192 bit, non una 256- bit chiave).

Un altro vantaggio della chiave intermedia è che consente di visualizzare i file. Ad esempio, hai il tuo grande file e vuoi mostrarlo a Bob. Ma tu non vuoi dare la tua password a Bob; vuoi che Bob sia in grado di vedere quel singolo file, non tutti gli altri file che sono moralmente crittografati con la stessa password. Con la chiave intermedia, questo è facile: basta mostrare K a Bob. Finché ogni file ha il suo K casuale, questo funziona.

Si noti che il modello si estende alla crittografia asimmetrica: un file inviato ai destinatari n verrà crittografato una volta con una chiave casuale K e K verrà crittografato con le chiavi pubbliche di ciascun destinatario. Ecco come funzionano le cose in OpenPGP . I vantaggi corrispondenti si associano anche alla situazione basata su password.

Permette all'utente di cambiare la password senza dover crittografare nuovamente tutti i dati.

Se hai usato direttamente la password per crittografare i dati, una modifica della password potrebbe richiedere molto tempo perché l'intero dato dovrà essere decifrato usando la vecchia password e cifrato nuovamente usando quello nuovo. E che dire se questo processo viene interrotto nel mezzo, quando metà dei dati viene crittografata con la nuova password mentre l'altra è ancora con quella vecchia?

Grazie al sistema che descrivi, quando gli utenti vogliono cambiare la sua password, tutto ciò che serve è crittografare la chiave dati con la nuova password. Semplice, veloce e affidabile.

Presumibilmente questa è convenienza. Se voglio cambiare la mia password, questo deriverà una chiave separata - quindi ho solo bisogno di ricodificare la chiave con la chiave di crittografia derivata dalla mia password.

Tuttavia, se non avessi una chiave separata, avresti bisogno di decifrare e ricodificare l'intero database. Poiché si tratta di password che non è probabile che siano enormi, ma per altre implementazioni (file system) la progettazione di chiavi multiple ha senso.

1. Alta entropia. Se la tua chiave dati è casuale, molto probabilmente non è il link più debole.
2. Separazione delle chiavi (non è sicuro se si chiami questo ...): un utente malintenzionato deve decidere se attaccare l'intestazione con la chiave "debole" o attaccare i dati con la chiave strong per la quale potrebbero essere presenti gigabyte di dati di esempio . Quindi gli attacchi crittoanalitici sono difesi.
3. Convenienza. Un utente può semplicemente cambiare la sua password senza la necessità di ricodificare i gigabyte di dati. (che può richiedere ore)

In realtà ciò che accade è che una password fornita dall'utente viene trasformata in un hash della lunghezza impostato in un'operazione matematica a una via chiamata SHA-256.

"SHA-256 è usato come hash della password SHA-256 è una funzione di hash unidirezionale crittograficamente a 256-bit. La tua password master viene cancellata usando questo algoritmo e il suo output è usato come chiave per gli algoritmi di crittografia."

Fondamentalmente si inserisce una password e si genera un hash SHA-256 unico con una lunghezza di 256 bit. La sicurezza della password deriva dalla sua casualità. La sicurezza dell'utilizzo dell'hash deriva dalla sua lunghezza e dalla natura unidirezionale della sua generazione.

La logica di questo richiede ancora una strong password fornita dall'utente, ma sì, l'altro punto è che vuoi che gli utenti siano in grado di ricordare una password non un hash casuale a 256 bit.

Ulteriori informazioni qui.

Penso che qui ci sia un po 'di confusione tra due diverse applicazioni Full Disk Encryption (ad esempio Truecrypt) e la generazione di password e schemi di archiviazione (ad esempio KeePass). Queste due situazioni hanno obiettivi e modelli di sicurezza molto diversi.

La prima applicazione Full Disk Encryption utilizza un approccio a più livelli per consentire una facile modifica delle chiavi, la minimizzazione dei dati crittografati con chiavi a bassa entropia e (in alcuni casi almeno) più metodi di recupero dati.

Se hai una chiave ad alta entropia casuale usata per la crittografia dei dati stai dando molte coppie P / C all'attaccante ma la chiave è anche strong. Il tasto entropia inferiore viene quindi utilizzato solo per alcune coppie P / C (forse 2-10 blocchi o giù di lì). Questo non è probabilmente un grosso problema in questi giorni, dal momento che crediamo che trovare un solo bit di una chiave o la sua parità sia difficile come trovarli tutti, ma è comunque meglio dare all'attaccante una superficie di attacco più piccola per la chiave peggiore.

Allo stesso tempo, per molti usi di FDE, potresti voler avere più persone con password / chiavi diverse in grado di accedere ai dati o avere un metodo di accesso diverso per un amministratore e poi un utente. Poiché la crittografia sottostante deve essere la stessa, si utilizza un'altra chiave per crittografarla con.

Per la seconda applicazione il modello di attacco è molto diverso. Considerando che per le applicazioni di TrueCrypt si presuppone che qualcuno abbia accesso a tutti i dati e le intestazioni contemporaneamente (rubano il tuo disco rigido), nel caso di KeePass di solito si presuppone che il luogo in cui le chiavi crittografate (il contenitore KeePass) sono memorizzato è diverso dai luoghi in cui vengono utilizzate le chiavi (i siti Web / server / carte di credito / cosa no). Ciò significa che in genere si presuppone che sia molto più difficile o costoso per l'aggressore attaccare le chiavi crittografate (il contenitore KeePass) e quindi lanciare un attacco contro il luogo in cui vengono utilizzate le chiavi.

Pensaci in questo modo: se la tua password per il tuo contenitore KeePass è "Princess" e tutte le chiavi sono generate casualmente prima che l'attaccante possa iniziare a scrivere e-mail mentre prima deve ottenere il contenitore KeePass dal nostro disco fisso e scopri che "Princess" è la tua password, dal momento che attaccare la chiave generata a caso che usi per accedere all'account email non è fattibile.

se invece la password del tuo account di posta elettronica è "Princess", tutto ciò che l'utente malintenzionato deve fare è provare le prime 10 o più password più comuni e può hackerare nel tuo account di posta elettronica.

Come bonus extra se per qualsiasi ragione tutte le password nel tuo database dei provider di posta elettronica sono compromesse, tutti i tuoi sistemi saranno al sicuro poiché le password che hai usato sono casuali e non correlate alla tua password di posta elettronica (KeePass li ha generati). Considerando che se si utilizza "Hard2h4ck" per la propria password di posta elettronica e "h.ard2H4ck" come password di amministratore per il server che gestisci la perdita di email, un attaccante può essere un buon punto di partenza per attaccare il server.

La risposta sta nel modo in cui crittografiamo. Se abbiamo appena usato una password o una chiave a 128-256 bit per crittografare i set di dati di grandi dimensioni, i dati sarebbero vulnerabili agli attacchi perché è più grande della chiave che lo crittografa. Un utente malintenzionato potrebbe facilmente analizzare i dati crittografati per i pattern e ricavare il testo in chiaro. Per essere sicuri, i dati devono essere crittografati con una chiave RANDOM almeno grande quanto i dati stessi (grande K).

Poiché il grande K stesso è statisticamente casuale, non ci sono schemi da analizzare. Pertanto possiamo tranquillamente utilizzare una chiave molto più piccola (128-256 bit k piccola) per crittografare il grande K e prevenirlo dall'esposizione involontaria. Dal momento che il grande K è già statisticamente casuale, la sua crittografia con una chiave molto più piccola lo espone a un rischio molto piccolo dalla crittanalisi, che dipende dallo sfruttamento di modelli in dati significativi. Per definizione, i dati casuali non contengono pattern.

Quindi la chiave più piccola nasconde in modo sicuro la chiave più grande, e apre le convenienze come gli altri spiegati sopra, come la gestione delle password degli utenti.

Una password decifra il piccolo k, il piccolo k decrittografa il grande K e il grande K decrittografa i dati.