Informazioni sull'efficienza: la crittografia simmetrica (come AES) di livello di sicurezza comparabile sarà sempre più veloce di quella asimmetrica (come RSA).
Per questo motivo (e dal momento che RSA ha bisogno di un padding casuale per essere sicuro, il che significa che il testo cifrato è un po 'più grande del testo in chiaro), il modo usuale di usare RSA (se devi cifrare più della dimensione della chiave) è per generare una chiave casuale per un algoritmo simmetrico, crittografare quella chiave con RSA, crittografare il testo in chiaro con questa chiave casuale e memorizzare la chiave crittografata insieme al testo in chiaro.
Quindi, la tua selezione è in realtà tra:
- RSA (con chiave pubblica + privata) insieme ad AES (o qualche altro algoritmo, ma restiamo semplici)
- solo AES (con una chiave segreta)
La crittografia attuale non è un punto in cui un utente malintenzionato può trarre alcun vantaggio: sia AES che RSA (con le dimensioni della chiave specificate) sono abbastanza sicuri da resistere agli attacchi di forza bruta.
Se si utilizza solo la crittografia simmetrica, ovviamente il server di crittografia ha bisogno di questa chiave e, se compromessa, questa chiave può essere utilizzata per decrittografare i dati nel database. Non c'è davvero un modo per aggirare questo.
Se si utilizza la crittografia asimmetrica, il server di crittografia potrebbe avere solo la chiave pubblica, ma questa è solo un'opzione valida se questo server webapp non ha mai bisogno di decrittografare nuovamente i dati, ad esempio per i dati di sola scrittura. Hai davvero questi dati? (Può essere modificato dopo averlo inviato, ma solo sovrascrivendolo, non prima leggendolo, cambiando e scrivendo.)
Inoltre, poiché si sta utilizzando una chiave pubblica per la crittografia, non c'è nulla che impedisca a un utente malintenzionato con accesso al database di modificare i dati in qualcos'altro. Se un utente malintenzionato accede in qualche modo al database (ovviamente non dovrebbe farlo), non è così complicato derivare la chiave pubblica dai dati crittografati. Avendo ciò, l'attaccante può semplicemente inserire nuovi record nel database, o sovrascrivere quelli vecchi, e il processo di decrittografia (con la chiave privata) non ha alcuna possibilità di vedere la differenza. Per evitare ciò, chiedi al processo di scrittura di firmare i dati (con la chiave privata di una diversa coppia di chiavi), in cui il processo di lettura può verificare queste firme.
Puoi avere un secondo server per decrittografarlo per il primo su richiesta, ma questo non sarà molto più sicuro di quello che il primo lo farà da solo (solo che puoi semplicemente interromperlo quando osservi la presenza dell'attaccante) .
Quindi, per stimare completamente la tua sicurezza, è necessario prima avere un modello di attacco (cioè contro quali attacchi vuoi essere sicuro), quindi puoi giudicare quale variante protegge meglio.
I want to be sure the Internet facing server doesn't get attacked.
La crittografia del database da sola non apre (o chiude) alcuna rotta di attacco sul server web, in entrambi i casi. Sono solo diversi se qualche attaccante trova un altro buco nella sicurezza nella tua applicazione web e ottiene l'accesso al server web .