La più grande difficoltà che avrai nella costruzione di questo sistema non è tecnica, ma più politica e legale. Sarai preso di mira da ogni governo nel mondo. Il governo sarà la tua più grande minaccia e non riesco a vedere dove potresti trovare un hosting adeguato senza una qualche forma di "backdoor / canale" per le agenzie governative.
Ad esempio, qui negli Stati Uniti, probabilmente riceverai una Lettera di sicurezza nazionale che significa che hai vinto " È anche possibile riconoscere di essere costretti a consegnare le chiavi. Il governo probabilmente promuoverà il terrorismo e il crimine come ragionamento per la NSL, quindi passerai molto tempo a cercare di farlo decollare in qualsiasi paese del mondo. Quindi sulle parti tecniche di questo, insieme agli ostacoli che dovrai superare per renderlo veramente sicuro.
Inizierò rispondendo alla tua ultima domanda: " C'è qualcosa che ci manca qui? " Ecco in sostanza ciò che stai cercando di fare
PersonUsingService —> connects to your systems —> encrypt/decrypt email
Scenario 1) La macchina di PersonUsingService è fuori controllo. Qualsiasi software dannoso (rootkit, logger di tasti, ecc.) Significa che il tuo sistema ha fallito, anche se ha fatto il suo lavoro. Immagina di aver costruito qualcosa che ha attirato l'attenzione di EFF / ACLU, hanno usato il servizio solo per scoprirlo, le loro comunicazioni sono finite su Pastebin . Tutto quello che sapranno è che ha attraversato i tuoi sistemi e, alla fine, la tua reputazione soffre.
Scenario 2) PersonUsingService's è MITM prima di raggiungere il tuo server. Di fatto, i governi collocano Narus tap su IXP e / o rubano a titolo definitivo il certificato o pagano pesantemente a una CA. Il tuo sistema fallisce.
Scenario 3) Ti prendi il tempo necessario per creare uno schema meraviglioso ma non hai mai protetto la tua infrastruttura interna, qualcuno fa clic accidentalmente su un link mentre si trova nella tua squadra di sviluppo. Permette ai governi o ai ladri di accedere al tuo sistema di chiavi.
Posso dare dozzine di esempi del perché questa è una battaglia persa. Mentre capisco da dove vieni nel chiedere un tale sistema, la realtà è che è molto complessa non dal lato tecnologico, ma dal campo giuridico.
Torna alle tue domande: "Memorizza le chiavi private (crittografate)" (fermato qui) NESSUNO, ma il proprietario della chiave dovrebbe avere accesso alla propria chiave privata altrimenti il sistema fallisce. L'intero scopo della crittografia era di mantenere private le chiavi private. In un mondo ideale, ci sarebbe comunque fiducia, in quello che inizialmente affermavi: "Le persone che vivono in paesi con regimi totalitari, oppressivi e altri minacciosi" devi ricordare questi tipi di regimi non hanno problemi a usare " Crypto Rubber Hose " per accedere ai tuoi sistemi (e alle tue chiavi).
Dal punto di vista tecnico, forse è meglio dare un'occhiata a Vanish e al modello emanato da loro, e costruisci intorno a questo. Ad esempio:
PersonUsingService —> log in —> create disappearing (24-48hr key) —> encrypt message
System —> 24-48 expiry —> erase keys
In qualcosa di simile a questo modello, era necessario preoccuparsi di memorizzare le chiavi poiché la probabilità di un "raid di risposta rapida" per ottenere una sospensione delle chiavi di crittografia è bassa. La mia percezione del motivo per cui nessuno sta spendendo tempo a rispondere a questo, è perché le aziende hanno provato questo in passato (Hushmail) e bruciato attraverso un sacco di soldi facendo così. Per non parlare, alla fine, la legge supera le opinioni personali, le convinzioni, ecc. Se un governo dichiara di rinunciare alle chiavi, hai una lotta per tutta la vita cercando di dimostrare il tuo punto.