Generazione corretta di chiavi RSA + AES

Question

Generazione corretta di chiavi RSA + AES

#1 da (1 voti)

2

Ai fini dell'apprendimento, sto creando un'applicazione di chat in cui le connessioni vengono effettuate tramite SSL / TLS e i messaggi vengono crittografati utilizzando AES-CBC-256 e le chiavi AES sono crittografate con RSA-2048.

Il tasto AES viene generato casualmente (AesProvider.GenerateKey ()) per utente per sessione (che significa una chiave per ogni persona con cui un utente sta chattando) e l'IV viene generato casualmente (AesProvider.GenerateIV ()) passando in la chiave generata, ogni volta che viene creato un messaggio (prima di essere inviato). Dal lato RSA, sto generando un nome di sessione casuale sicuro per memorizzare le chiavi private generate nei contenitori e l'invio della chiave pubblica. Sto anche usando lo stesso modello (una coppia di chiavi per utente per sessione) come in AES.

Dovrei anche dichiarare che sto usando HMAC-SHA512 per cancellare i messaggi e inviare la chiave HMAC crittografata usando la stessa chiave pubblica con cui la chiave AES / Iv viene crittografata. Da quando ho letto che non ha bisogno di essere rigenerato spesso, sto pensando di rigenerare la chiave HMAC ogni 5000 o 10000 chiamate.

Domande: 1) Dovrei creare solo una coppia di chiavi RSA per utente e usarla per tutte le sessioni, o è buono come è adesso? 2) Sta usando lo stesso tasto AES e solo la modifica della IV come spiegato sopra è considerata sicura?

encryption

posta Camilo Terevinto 06.11.2015 - 16:51

fonte

1 risposta

Leggi altre domande sui tag encryption

Strange Accedi ad Apache Come proteggere le directory Web consentendo solo a me di accedervi

score 1 · Accepted Answer

A quanto pare si usa RSA per fare uno scambio di chiavi: la parte A vuole avere un segreto condiviso con la parte B (ad esempio una chiave adatta da alcuni AES o HMAC); quindi la parte A genera un valore casuale K e crittografa K con la chiave RSA pubblica di B. B utilizzerà la sua chiave RSA privata per eseguire la decrittografia e recuperare K .

Questo processo funziona solo finché la parte A utilizza per la crittografia una chiave pubblica RSA che appartiene realmente al destinatario previsto (B). A potrebbe ricordare la chiave pubblica di B da un'interazione precedente, o potrebbe esserci un repository centrale affidabile, forse un repository "virtualizzato" (questo è il significato dei certificati). In ogni caso ci deve essere qualcosa per impedire agli attaccanti di spingere le loro proprie, false chiavi pubbliche RSA al posto di quelle genuine. Questo non è un problema facile da risolvere. Se generi nuove coppie di chiavi su base per sessione, allora quel problema diventerà molto più difficile.

Ad ogni modo, quando usi SSL (che è una buona idea), ottieni già quel tipo di meccanismo per tutte le comunicazioni da client a server. I client SSL utilizzano la chiave pubblica del server SSL (nel certificato del server) per stabilire un segreto condiviso con quel server. Non si vede nulla di tutto questo perché è tutto nascosto nella libreria SSL; ma è lì. Se si desidera una crittografia aggiuntiva, è necessario presupporre che si desidera la crittografia da utente a utente, poiché il server centrale non è affidabile. (Se si desidera solo un po 'di crittografia tra ogni client e il server, questo sarebbe completamente ridondante con SSL.)

Per la crittografia da utente a utente, ogni utente A deve in qualche modo conoscere la chiave pubblica di ogni altro utente B con cui A desidera parlare. La distribuzione di tali chiavi pubbliche è il problema principale, perché si desidera bloccare le chiavi false, ma non si ha fiducia nel server centrale per mantenere l'ordine (se si ha fiducia nel server centrale, allora si lascerebbe semplicemente fare il lavoro a SSL). Puoi esaminare la nozione di Web of Trust per un possibile modello di distribuzione di chiavi pubbliche decentralizzate.

Per la crittografia simmetrica, l'intero punto di generazione della nuova IV è infatti quello di essere in grado di riutilizzare in modo sicuro le chiavi di crittografia simmetriche. Finché si genera correttamente un IV (CBC richiede IV casuale, uniforme, imprevedibile), questo dovrebbe andare bene.