È certamente possibile implementare un sistema che utilizza la crittografia end-to-end e la porzione del server scritta in PHP [1] . Dovrai solo implementare la parte crittografica come qualcosa che gira sui "fini" - cioè, i browser, così realisticamente dovrai implementarlo in JavaScript - e il tuo codice PHP servirebbe questo JS agli endpoint. Il codice PHP dovrebbe anche servire le chiavi pubbliche [2] per tutti coloro che dovrebbero avere accesso ai dati che vengono crittografati. A seconda di come archiviare le chiavi private, il PHP probabilmente memorizzerebbe (e servirà) una versione "incartata" (cioè crittografata) di quelle.
La porzione lato server (PHP) di questo intero progetto finisce per essere leggermente più complicata di una tipica applicazione web. Deve essere in grado di autenticare gli utenti, che è normale, ma senza abilitare gli amministratori a impersonare gli utenti (questo non è normale) [3] . Probabilmente ha bisogno di essere in grado di memorizzare (e controllare l'accesso a) dati privati per utente (le chiavi segrete avvolte), dati pubblici per utente (le chiavi pubbliche) e dati condivisi ad accesso limitato (i dati utente crittografati effettivi ). A seconda del tipo di dati che vengono archiviati, in che misura, se è necessario essere in grado di regolare chi ha accesso ad esso dopo il fatto e se ha bisogno di qualsiasi tipo di ricercabilità, è possibile imbattersi in una qualsiasi di host di ulteriori complessità. I sistemi end-to-end sicuri sono difficili . [4]
La porzione lato client (JS) di questa cosa sarà dove si verifica il sollevamento pesante, cripto-saggio, però. È un po 'imbarazzante, perché JS non è bravo a criptare. Esistono pure implementazioni JS delle funzioni crittografiche standard, ma tendono ad avere problemi (ad esempio essere relativamente lenti e potenzialmente esposti a vulnerabilità di canali secondari come gli attacchi temporali). Alcuni browser supportano l'esecuzione di operazioni di crittografia nativa utilizzando i dati di JS, che è più veloce e più sicuro (supponendo che tu abbia fiducia nello sviluppatore del browser, di cui hai bisogno in questo caso), ma non è ancora universale.
[1] Probabilmente non dovresti . PHP è una scelta sbagliata per qualsiasi codice altamente sensibile alla sicurezza, in quanto è relativamente facile fare errori di sicurezza. Il codice di sicurezza in PHP (completo, aggiornato) è certamente possibile, ma raccomanderei l'uso di un linguaggio che lo rende più difficile sparare a piedi, come Java, C #, VB.NET, o forse Go o Python.
[2] Questo presenta un punto debole di sicurezza che devi capire, perché il sistema endpoint - l'utente e il suo browser web - non ha modo di dire se le chiavi pubbliche inviate al client (a che i dati vengono crittografati) sono le chiavi pubbliche destra . Un amministratore di server malintenzionato potrebbe aggiungere la propria chiave pubblica all'elenco di chiavi e quindi qualsiasi dato crittografato con quell'elenco di chiavi sarebbe leggibile dall'amministratore malintenzionato. Hai bisogno di un modo per verificare l'autenticità della chiave.
[3] Un po 'complicato è che, mentre il server non dovrebbe mai memorizzare la password dell'utente, il server in genere vede la password, brevemente, durante la creazione dell'account e ogni volta che la password è utilizzata (accesso, modifica della password, ecc.). Un amministratore di server dannoso potrebbe modificare il server per rubare questa password. Se quella password è tutto ciò che è necessario per accedere come tale utente - ad esempio, se conoscere la password dell'utente consente di scartare la chiave privata dell'utente - l'amministratore malintenzionato potrebbe quindi decrittografare i dati che non dovrebbero avere accesso impersonando un utente legittimo.
[4] Onestamente, questo sembra un progetto per qualcuno che sia più esperto nella sicurezza delle informazioni sia come sviluppatore. Non è un problema facile, e crypto è difficile da fare bene.