La complessità è il nemico della sicurezza. Così sta abbandonando il controllo dei bit importanti, come le chiavi, quando non è necessario.
A quanto ho capito, il tuo schema funziona in questo modo:
- L'utente avvia l'app client che può accedere ai file locali crittografati
- L'utente inserisce a) nome utente e b) password
- Nome utente e password vengono trasmessi al server
- Il server autentica l'utente con nome utente e password
- Il server utilizza un KDF per ricavare una chiave di crittografia dalla password dell'utente
- Il server decrittografa la chiave memorizzata dell'utente utilizzando il tasto derivato
- Il server trasmette la chiave decrittografata all'app client
- L'app client decrittografa i file utilizzando il tasto
Tuttavia, tutto ciò di cui hai veramente bisogno sono 1, 2b, 5 e 8. I passaggi 2a, 3, 4, 6 e 7 non sono necessari e aggiungono semplicemente dei rischi.
Nel modello più semplice:
- L'utente avvia l'app client che può accedere ai file locali crittografati
- L'utente inserisce la password
- L'app client locale utilizza un KDF per ricavare una chiave di crittografia dalla password dell'utente
- L'app client decrittografa i file utilizzando il tasto
In questo modello, non è richiesta la memorizzazione persistente delle chiavi, nessun server in possesso di un tesoro di chiavi e hash crittografati che potrebbero essere attaccati e utilizzati per la password brute-force, nessuna trasmissione Internet di dati sensibili.
La tua domanda non menziona alcun motivo particolare per volere o bisogno di un server che memorizza le chiavi. Assente quel bisogno, penso che dovresti ripensare al tuo modello di minaccia, perché il design attuale non ha molto senso per me.