Oui bien sûr 
Et alors ? Ça n’empêche pas un stockage chiffré… Parce que les gens consultent depuis ces terminaux en utilisant leur mot de passe. Donc avec une clé de chiffrement dérivée du mot de passe, leur PC perso, leur smartphone, etc… peuvent connaître la clé de déchiffrement, sans pour autant que le serveur ait besoin de la connaître (il n’a besoin de connaître que le hash salé du mot de passe, pour authentifier l’utilisateur).
Il existe plein de services avec chiffrement de bout en bout qui fonctionnent très bien sur PC, smartphone, etc…
Voilà en simplifié le processus :
À l’inscription :
- l’utilisateur saisit un mot de passe sur son poste,
- du code s’exécutant côté client (JavaScript par exemple) calcule un hash salé (avec un sel qui peut être soit aléatoire, soit dérivé de l’identifiant ou du mot de passe, soit fourni par le serveur) du mot de passe, calcule une clé maîtresse dérivée du mot de passe et génère une paire de clés RSA,
- le client chiffre la clé privée,
- le client envoie le hash salé et son sel (s’il est aléatoire), la clé privée chiffrée et la clé publique au serveur.
Lors de la prise de rendez-vous :
- l’utilisateur saisit son identifiant et son mot de passe,
- le client demande au serveur le sel associé à cet utilisateur (si le sel est aléatoire ou fourni par le serveur),
- le client calcule le hash salé du mot de passe et l’envoi au serveur,
- si le hash est ok, le serveur renvoie au client la clé privée chiffrée avec la clé maîtresse et la clé publique,
- le client calcule la clé maîtresse et déchiffre la clé privé,
- le serveur envoie les données chiffrées au client,
- le client déchiffre les données avec la clé privée => il a désormais les données en clair, sans qu’elles aient jamais transité par le serveur et sans que le serveur ait jamais eu les informations nécessaires pour déchiffrer.