RSA 4096 con processo di crittografia AES 256 utilizzando PyCrypto

Il mio feedback principale: non fornisci sufficienti dettagli tecnici per fornire una critica completa della proposta, ma hai fornito informazioni sufficienti che posso vedere che stai commettendo diversi errori comuni. Ecco i principali errori che riesco a vedere finora:

• Errore n. 1: inventare il proprio formato di crittografia. Di solito, progettare il proprio formato per la memorizzazione di dati crittografati non è una buona idea ; è probabile che tu abbia qualcosa di sbagliato. È preferibile utilizzare un formato standard, come GPG o il formato messaggio OpenPGP.

• Errore 2: mancata inclusione della protezione dell'integrità dei messaggi La crittografia dei dati senza anche l'autenticazione ti apre a attacchi sottili ma gravi . Questo è altamente contro-intuitivo e un errore molto comune. Si è tentati di pensare, ciao, voglio mantenere questo segreto, quindi se lo cripto con un buon algoritmo di crittografia, starò bene. Ma no, non starai bene. È inoltre necessaria l'autenticazione dei messaggi, per difendersi dagli attacchi con testo cifrato scelto. E devi applicare con una modalità corretta (ad esempio, crittografia autenticata o Encrypt-then-MAC) e con una corretta gestione delle chiavi (chiavi indipendenti per l'autenticazione e la crittografia, o l'uso appropriato della separazione delle chiavi).

Per evitare questi problemi, segui il consiglio ai link che ho indicato sopra.

Altri feedback vari:

• Potrebbero esserci altri problemi; non ci hai fornito abbastanza informazioni per identificarle tutte. Ecco alcuni esempi di potenziali problemi:

  • Ad esempio, non descrivi come viene generata la IV. Nei sistemi del passato, la scarsa generazione di IV ha occasionalmente portato a problemi di sicurezza. (L'IV deve essere generato utilizzando un generatore di numeri pseudocasuali con crittografia).

  • Non descrivi come la chiave AES sia crittografata. (È necessario utilizzare uno schema di riempimento adeguato, ad es. OAEP o PKCS # 2.)

• Le lunghezze della chiave che hai selezionato sono eccessive.

• Tieni presente che, quando la crittografia moderna viene implementata e utilizzata correttamente, non è quasi mai il link più debole del sistema.

  Invece, gli attaccanti di solito sconfiggono la crittografia non rompendo gli algoritmi crittografici, ma bypassando la crittografia e attaccando qualche altro aspetto del sistema - magari applicando l'ingegneria sociale agli umani, forse trovando un buco nel codice di sicurezza e compromettendo un endpoint, magari sfruttando gli errori nella gestione delle chiavi o in una serie di altri modi per attaccare un sistema.

Non esiste "abbastanza sicuro" a meno che non si definisca un modello di attacco, che è l'elenco di poteri che si ritiene che l'autore dell'attacco previsto abbia.

Sebbene, come commento di base, non vi sia alcun controllo di integrità qui, gli aggressori attivi si divertiranno con i tuoi dati. Inoltre, non si dice nulla sulla modalità di crittografia (ECB, CBC, CTR ...?) E sulla gestione IV associata, quindi è possibile che si sia incasinato (non è difficile, è facile sbagliare, è difficile ottenere destra). Le dimensioni delle chiavi sono eccessive, quindi sei un'amministrazione governativa con più cicli della CPU che sai cosa fare o sei un po 'paranoico o entrambi. Inoltre, stai inventando la tua crittografia personale, e questo è male, perché è molto più facile incasinare di quanto non sia in realtà notare che l'hai incasinato.

1. Solo il tasto AES è segreto. La CBC IV non è un segreto, a patto che non si riutilizzi mai una flebo. Ogni volta che crittografa un messaggio con CBC, puoi anteporre il ciphertext al IV e archiviarlo come testo cifrato. Quando decifri il messaggio, ricorda semplicemente che il primo blocco è il IV.

2. Non includi alcun controllo di integrità. È possibile generare una firma in vari modi, ma è necessario ricordare di non firmare e crittografare mai utilizzando la stessa coppia di chiavi RSA. Un modo per generare una firma è generare in modo casuale una seconda chiave per HMAC, ottenere una sintesi del testo cifrato con HMAC-SHA512 e la chiave generata, quindi crittografare e memorizzare la chiave HMAC generata insieme alla chiave AES generata. Se segui la pratica di concatenare l'IV con il testo cifrato, dovresti applicare HMAC-SHA512 al testo cifrato concatenato IV +, non solo il testo cifrato originale.

3. Non hai specificato questo in un modo o nell'altro, ma il tasto AES, l'CBC IV e la chiave HMAC devono essere tutti generati da un generatore di numeri pseudo-casuali crittograficamente sicuro (PRNG cryptorandom), a meno che tu capita di avere a portata di mano un vero RNG.

4. Esistono formati standard generali per la serializzazione di messaggi crittografati. È possibile scegliere di utilizzarli al posto di memorizzare i byte non elaborati dei testi cifrati e dei digest. Gli standard includono il formato dei messaggi OpenPGP e Sintassi dei messaggi crittografici .

Si noti che il n. 1 non è strettamente un problema di sicurezza, ma in pratica il problema è che le persone sono spesso confuse su quali parti del sistema devono essere segrete e quali parti possono essere pubbliche e quale sia il contesto corretto per queste regole e tale confusione porta spesso ad errori. Lo scopo dell'IV è fornire un alto grado di entropia per la crittografia del primo blocco del testo in chiaro, non per essere una sorta di seconda chiave.