La domanda da porsi è: il server dovrebbe poter accedere al valore?
Se il server deve essere in grado di accedere al valore, la "crittografia per lo storage" è solo un'illusione. Un utente malintenzionato che ottiene il controllo del server sarà in grado di leggere i valori, poiché un tale utente malintenzionato può fare tutto ciò che il server può fare. Si potrebbe voler applicare un po 'di "crittografia" sul database stesso se si considera che il database sia "meno sicuro" (o "distintamente sicuro") rispetto al server (ovvero si immagina un utente malintenzionato che ottiene una sbirciatina di sola lettura nel database ad esempio rubando un nastro di backup); in tal caso, è meglio applicare un sistema di crittografia dell'intero database, che sarà più completo, più semplice e più efficiente, rispetto alla semplice concentrazione sui due valori (in Microsoft SQL Server, questo è chiamato Crittografia dati trasparente ).
Se il server non deve essere in grado di accedere al valore, l'applicazione client deve eseguire la crittografia e la decrittografia, il che solleva il problema della gestione delle chiavi. L'applicazione client deve avere una chiave specifica dell'utente che memorizza e quindi utilizza per decrittografare e crittografare i dati. C'è molto spazio per errori grossolani qui, quindi è meglio scegliere un protocollo e un formato ben controllati per questo. Un modo è quello di crittografare i dati con una chiave derivata da una password utente; il formato OpenPGP ha un certo supporto per questo.