Ho programmato un semplice "codificatore" One-Time Pad in grado di unire due file in uno utilizzando XOR bit a bit.
I file chiave pseudo casuali vengono generati utilizzando CryptGenRandom() funzione della libreria CryptoAPI di Microsoft. Ora mi chiedo se codificare o meno plug-in per i generatori di numeri casuali True.
La mia domanda è: quali sono i problemi pratici nella distribuzione di OTP con TRNG, oltre a richiedere agli utenti di avere l'hardware speciale in primo luogo?
Per prima cosa, prendiamo una terminologia corretta. Per chiamare qualcosa a one-time-pad , la chiave deve essere veramente casuale . Quindi con questo in mente:
Hai quasi fatto due domande separate:
Sto usando CryptGenRandom () per generare la mia chiave. è abbastanza buono o dovrei considerare l'utilizzo di un TRNG?
Se utilizzo un TRNG, quali sono i problemi pratici, se ce ne sono, nella distribuzione di OTP con TRNG?
Per la domanda 1, a quanto ho capito, l'unico modo in cui qualcuno ha mai superato con successo (cioè rigenerato il seme corretto) per CryptGenRandom () è ottenendo l'accesso alla macchina originale in cui è stata creata la chiave. E quello stava usando un difetto in Windows 2000 che è una tecnologia vecchia di 15 anni. Quindi, sulla base di ciò (combinato con le persone intelligenti di MS che affermano che è crittograficamente sicuro), direi che sì, CryptGenRandom () dovrebbe essere praticamente abbastanza buono da essere utilizzato per la generazione delle chiavi.
Detto questo, alcune crittografia ad alto bit dovrebbero essere abbastanza buone, e se qualcuno sta pensando di usare OTP invece di qualche altro metodo di crittografia, è probabile che sia paranoico al punto che abbastanza buono non lo taglierà In altre parole, se hai intenzione di implementare qualcosa che puoi veramente chiamare OTP, deve essere assolutamente impossibile per decifrare la tua implementazione senza la chiave, che non puoi realizzare a meno che tu non usi un TRNG.
Per quanto riguarda la domanda 2, IMHO, non ci sono problemi pratici nell'uso di un TRNG. Il motivo è che solo 1 parte fidata coinvolta nella comunicazione deve avere il TRNG, non tutti. Il problema più difficile riguarda la distribuzione delle chiavi, non la generazione delle chiavi. La parte con il TRNG (dongle USB o qualche altro aggeggio) potrebbe generare un ampio set di dati casuali e quindi distribuire i dati a tutte le parti coinvolte. Ogni parte quando invia una comunicazione dovrebbe semplicemente specificare l'offset nei dati casuali in cui inizia la propria chiave. Quando il set di dati casuali è esaurito, è possibile generare un nuovo set di dati.
Tuttavia, il fatto che qualcuno coinvolto in ogni comunicazione debba inizialmente ottenere un dispositivo hardware per creare la chiave può essere considerato un "problema", a seconda di come lo si guarda. Ciò potrebbe avere un effetto sul tuo "tono di vendita", per così dire, dal momento che non ti attirerai con gli utenti impulsivi che vogliono inviare un messaggio con cifratura infrangibile adesso ; tutti i nuovi utenti dovranno attendere un po 'di tempo per ottenere il dispositivo TRNG. Potresti prendere in considerazione l'utilizzo di un servizio come www.random.org , ma se lo fai, i tuoi utenti ultra-paranoici potrebbero non gradire In effetti, la chiave viene scaricata su measly SSL!
TLDR; Indipendentemente dal fatto che tu usi CryptGenRandom () o un TRNG, la parte difficile non è in realtà nella generazione della chiave, ma nella distribuzione delle chiavi a ciascuna parte in modo che possano decifrare il messaggio.
Leggi altre domande sui tag random encryption file-encryption one-time-pad