Se si desidera memorizzare i dati in modo che la persona che detiene i dati non possa leggerli, quindi
- Devi crittografare i dati lato client. La crittografia lato server apre la possibilità che qualcuno (ad esempio, l'operatore del servizio) possa registrare i dati mentre è in transito.
- La crittografia deve essere eseguita utilizzando le chiavi selezionate dal cliente. Se qualcun altro fornisce le chiavi, possono registrarle.
- Il client deve essere memorizzabile offline (quindi l'operatore del servizio non può manometterlo dopo il fatto) e dovrebbe avere il codice sorgente disponibile (in modo che l'utente possa verificarlo per assicurarsi che faccia ciò che dovrebbe).
Per impedire all'operatore del servizio di associare dati con un account, l'operazione "store" non è "associa un nuovo record con questo account", ma "memorizza un record taggato con questo hash", dove viene fornito l'hash in questione dal client (ad esempio, un hash salato della loro password, dove il sale è il numero di indice del record desiderato). Al contrario, l'operazione di recupero non è "seleziona record associati a questo account", ma "seleziona i record contrassegnati con questo hash". Inoltre, le operazioni "store" e "retrieve" non possono richiedere l'accesso dell'utente. Probabilmente c'è un modo per un utente di dimostrare di avere un account senza rivelare quale account è, ma io so come si fa.
Teoricamente, ogni utente può richiedere i record di altri utenti, sebbene con un hash a 256 bit, le probabilità di qualsiasi richiesta casuale che restituisce un valore sono estremamente rare (1 su 10 ^ 68, se hai un miliardo di record memorizzati ). Dal momento che un utente malintenzionato non ha la password di decrittografia, essere in grado di recuperare il record di qualcun altro ha poco valore.