Crittografia: dovrei usare RSA o AES?

Né, a meno che non sia entrambi. stai facendo la domanda sbagliata . Non dovresti pensare a un algoritmo crittografico in questa fase, ma a un protocollo crittografico.

I protocolli crittografici sono difficili da progettare e una fonte frequente di bug di sicurezza. Non comprendi completamente la crittografia a chiave pubblica, quindi non sei pronto per utilizzarlo nel tuo protocollo crittografico.

Ad un livello elevato, il tuo modello è suscettibile di crittografia a chiave pubblica (ad esempio RSA). Lascia che ogni client abbia la sua chiave privata e pubblichi la sua chiave pubblica sull'altro client. La chiave privata di un cliente non cambia nel tempo, a meno che il client non sia stato compromesso. La crittografia simmetrica (ad esempio AES) non si adatta bene qui perché ogni coppia di client dovrebbe avere la propria chiave segreta.

Utilizza il software esistente quando possibile. L'implementazione di protocolli crittografici è quasi difficile come progettarli. Per un modello in cui i clienti di tanto in tanto inviano messaggi a vicenda, in stile e-mail, uno strumento che funzionerebbe bene è GnuPG . (Per comunicazioni bidirezionali, utilizza SSL / TLS .)

Quindi: per le operazioni quotidiane, per inviare un messaggio, chiamare gpg , crittografare con la chiave pubblica del destinatario e mentre ci si trova a firmare con la chiave privata del mittente. Quando si riceve un messaggio, controllare la firma con la chiave pubblica del presunto mittente e decrittografarlo con la chiave privata del destinatario. In altre parole, invia con gpg --sign --encrypt -r NAME_OF_RECIPIENT e ricevi con gpg --verify seguito da gpg --decrypt .

Il problema rimanente è quello della distribuzione delle chiavi. Dopo che un client ha generato la sua coppia di chiavi, deve informare gli altri client su di esso e distribuirlo senza consentire che la chiave pubblica venga intercettata e sostituita in transito da un utente malintenzionato. Come fare questo dipende molto dal tuo preciso scenario. Non trascurare la sicurezza di questa parte.

Se, e solo se, invocando GnuPG risulta essere troppo lento, allora considera di usare un'implementazione più leggera, forse fatta in casa, di un protocollo simile (passando dall'overhead del range di posta elettronica al sovraccarico degli SMS). Sotto la cappa, GnuPG genera una chiave simmetrica per ogni messaggio, perché la crittografia a chiave pubblica è costosa per i messaggi di grandi dimensioni; l'algoritmo a chiave pubblica viene utilizzato solo per crittografare la chiave simmetrica e per firmare un digest del file. Dovresti seguire questo modello. Utilizzando AES per la crittografia simmetrica, SHA-256 come algoritmo di digest e RSA come algoritmo a chiave pubblica è una buona scelta.

Come già detto da In silico, RSA e AES hanno due scopi diversi. AES è un algoritmo veloce, adatto per crittografare un'intera conversazione. Ma ha un problema: come decidere quale chiave usare tra due parti senza che gli altri lo sappiano?

RSA può essere la soluzione a questo. Se ogni partecipante ha la chiave RSA pubblica di ogni altro partecipante, chiunque può avviare una comunicazione crittografata con chiunque altro (utilizzando la chiave pubblica dell'altro partecipante) e decidere una chiave AES segreta da utilizzare. Una volta deciso il tasto AES, il resto della conversazione può essere crittografato utilizzando AES. Per dimostrare che per il partecipante B è davvero A che vuole parlare con lui, può essere usata una firma digitale.

Quello che ho descritto è, grosso modo, che cosa fa l'handshake SSL quando un browser si connette a un server Web abilitato per SSL.

Non prenderla nel modo sbagliato ma ...

I know the rough basics of how RSA and AES work but I can't figure out what is best.

Se conosci solo le basi, potresti non essere la persona giusta a risolvere questo problema (ancora). La sicurezza è una di quelle aree in cui è necessario essere molto particolare e attento, altrimenti si invalida l'intera configurazione di sicurezza.

Inoltre, non credo che abbiamo abbastanza informazioni per darti una risposta adeguata. I contratti commerciali relativi alle aspettative sulla sicurezza dovranno essere conosciuti in anticipo.

Nella maggior parte dei casi le chiavi non abbandonano mai la macchina sulla quale sono generate per motivi di sicurezza, quindi se si intende "condividere" le informazioni, una soluzione a chiave pubblica di solito è la scelta giusta da un punto di vista puramente di sicurezza. L'eccezione è se è possibile condividere una chiave simmetrica in modo sicuro, ad esempio l'invio della chiave alla persona su un supporto fisico.

Fondamentalmente, l'uso della crittografia a chiave pubblica (come RSA) è molto più costoso dell'uso della crittografia a chiave simmetrica (come AES), e quando ci sono molti messaggi che passano da uno all'altro, è meglio usa una chiave simmetrica.

Ora, la creazione e lo scambio della chiave simmetrica possono essere eseguiti utilizzando la crittografia a chiave pubblica.

Ad esempio:

Ogni client ha una coppia di chiavi pubblica-privata e la chiave pubblica è memorizzata sul server. Quando due client avviano una sessione di comunicazione, ciascuno prende la chiave pubblica dell'altro dal server e invia un numero crittografato all'altro. Quindi ogni lato esegue l'hashing di questi due numeri e utilizza il risultato come chiave per crittografare / decodificare i dati da ora in poi.

Se usi lo stile PUBLIC / PRIVATE (RSA con bit sufficienti :)) puoi impostare il tipo di comunicazione sicura che descrivi in questo modo:

1. Alice scrive un messaggio
2. Alice lo crittografa utilizzando il tasto di Alice
3. Alice lo cripta di nuovo usando la chiave PUBLIC
di Bob
4. Alice invia i risultati a Mario.

1. Bob riceve un messaggio (presumibilmente) da Alice
2. Bob lo decifra utilizzando il tasto di PRIVATE
di
3. Bob lo decrittografa nuovamente utilizzando la Alice PUBLIC chiave
4. Se tutto va bene, Bob legge il messaggio.