Non ci sono.

Le correlazioni crittografate tra le voci richiedono la decrittografia e sono quindi lente. Tuttavia, le correlazioni non crittografate sono vietate dai requisiti. Ne consegue che sei costretto a utilizzare uno schema lento.

Soluzione alternativa accettabile: dividi i log

Utilizzare una tabella crittografata diversa per ciascun utente, con il nome della tabella selezionato a caso e memorizzato come proprietà del profilo crittografato. Nei sistemi in cui le tabelle crittografate vengono decodificate al volo in memoria per ciascun utente, ciò consentirà di ottenere prestazioni.

L'unica informazione trapelata è il numero di utenti, che è probabilmente noto comunque dalla dimensione della tabella utente, e il fatto che alcuni utenti potrebbero avere più o meno voci di registro di altri. L'osservazione delle dimensioni delle tabelle consentirà di determinare quale identificatore univoco mapperà a quale utente, ma non di più.

Soluzione possibile accettabile: offuscare la correlazione

Invece di una relazione uno-a-uno, potresti prendere in considerazione l'utilizzo di una relazione uno-a-molti, in cui l'utente N può generare qualsiasi ID a caso del modulo N P + RAND (P-1). I record dell'utente N sono tutti quelli con ID nell'intervallo [N P, (N + 1) * P-1) e possono essere recuperati con una clausola BETWEEN. L'ispezione di un utente malintenzionato sul tavolo rivelerà una debole correlazione tra i record, con duplicati in media di TABLESIZE / P che verranno mappati tutti allo stesso utente.