Xifratge d'extrem a extrem, amb les claus als teus propis dispositius

Hi ha un secret a l'arrel del teu compte, i es crea en un dispositiu — no l'emet cap servidor. Tota la resta se'n deriva mitjançant un arbre de claus: una arrel HMAC-SHA-512, i després un pas d'HMAC per cada element de ruta etiquetat. El parell de claus que obre les claus de sessió segellades surt d'aquest arbre sota l'etiqueta "content", i també en surt una clau separada per a cada altra mena de blob emmagatzemat, així que cap clau no fa dues feines.

Per això un navegador acabat d'estrenar pot iniciar sessió al teu compte i tot i així no mostrar-te res de la setmana passada. Iniciar sessió demostra al relay qui ets. Llegir una sessió antiga necessita la clau, i la clau no és al relay per enviar-la. Restaurar el dispositiu és el pas que la mou — des d'un dispositiu que ja la té, o des de la clau secreta que vas guardar.

També vol dir que el cas de pèrdua és real i val la pena dir-ho un cop: si tots els dispositius amb la sessió iniciada han desaparegut i la clau secreta ha desaparegut amb ells, les sessions xifrades no les podem recuperar ni nosaltres ni ningú. Un relay que les pogués tornar seria un relay que les podria llegir.

Afegir un dispositiu és el moment en què es mou material de claus, així que és el moment que val la pena entendre. Escanejar el codi QR genera una petició, i això és tot el que fa: l'aprovació passa en un dispositiu que ja té la sessió iniciada, i quan les dues pantalles mostren un codi curt de confirmació se suposa que els has de comparar abans d'aprovar.

El que fa l'aprovació en realitat és segellar la clau de contingut amb la clau pública del dispositiu que l'ha demanada, en un sobre que porta una clau d'emissor efímera i un nonce nou. Aquest sobre viatja pel relay com tota la resta. Connectar un terminal hi afegeix una lligadura més a sobre: la càrrega útil s'autentica contra un secret d'aparellament que ha viatjat dins del codi QR i no pel servidor, així que un relay que canviés la càrrega útil no podria produir una etiqueta coincident.

Tot el que hi ha més amunt descriu el valor predeterminat, i el valor predeterminat no és un suggeriment que el client pugui negociar amb el servidor. Un relay acabat d'instal·lar està configurat per exigir emmagatzematge xifrat d'extrem a extrem: una escriptura en text pla es rebutja amb un error de política en lloc d'acceptar-se en silenci. Els clients llegeixen la política de l'endpoint de features del servidor abans de crear una sessió, així que el mode en què està una sessió es va acordar abans del seu primer missatge.

Un operador de servidor té dos ajustos més disponibles. Un pot permetre que un compte triï, de manera que les sessions xifrades i les de text pla convisquin al mateix relay — cal tant la política opcional com el permís d'exclusió, i el permís està desactivat tret que l'operador l'activi. L'altre exigeix text pla, per a organitzacions que gestionen el xifratge a la capa d'infraestructura i necessiten que el servidor pugui llegir i processar el contingut de les sessions. Aquest últim és un compromís real i val la pena dir-ho sense suavitzar-ho: en una sessió en text pla el servidor pot llegir la transcripció. Aquest és el sentit de l'ajust.

El mode es fixa per sessió en el moment de crear-la, així que cap sessió no és mai meitat i meitat, i canviar el mode d'un compte canvia què passa amb les sessions noves en lloc d'arribar a les antigues. Res no es desxifra retroactivament, i res no es xifra retroactivament tampoc.

Les variables que estableixen totes tres coses, les opcions en repòs que hi ha a sota i els controls d'identitat que les envolten són la meitat que correspon a l'operador, i viuen a la pàgina d'autoallotjament per a equips.

Una notificació push és l'única cosa que se surt del model, perquè ha d'arribar a un telèfon que no té res obert. La resposta de Happier és que les envia el teu propi ordinador. El servidor desa els teus tokens de push; la CLI del teu propi ordinador els torna a llegir i envia la notificació ella mateixa, cosa que manté el relay fora d'un camí en què altrament se li hauria d'explicar el contingut.

El que porta la càrrega útil és deliberadament prim: el tipus d'eina o de petició, i una pista curta quan ajuda — un fitxer com ara src/file.ts, un nom d'ordre, un recompte com ara "3 questions". L'entrada bruta de les eines no s'hi posa. Prou per decidir si val la pena agafar el telèfon, en una pantalla que pot llegir qualsevol que et sigui al darrere.

Tot això es compleix en un relay que no executes tu. El motiu per executar el teu és la fila de dalt sobre identificadors i forma: el xifratge no amaga qui parla amb qui, ni amb quina freqüència, i en un relay teu aquell registre també és teu. Una sola ordre posa el relay en maquinari que és teu, i el camí passa a ser el teu dispositiu, el teu relay, el teu ordinador, sense res que no hi hagis desplegat tu.

En aquesta pàgina no hi ha cap certificació perquè no n'hi ha cap per informar-ne, i una pàgina de seguretat que insinua un compliment que no té és pitjor que una que no l'esmenta. El que hi ha en lloc seu és el codi des del qual s'ha escrit cada frase de dalt, amb llicència MIT i llegible abans d'executar-lo: les primitives a packages/protocol/src/crypto, el xifratge de sessions a apps/cli/src/api/encryption.ts, la política d'emmagatzematge que el servidor aplica al seu endpoint de features, i l'esquema que mostra exactament quines columnes són en text pla.

Aquesta és també la resposta honesta a com hauries de tractar aquesta pàgina: com un mapa d'on mirar, no com una promesa per creure't. Llegeix els quatre fitxers, o executa el relay tu mateix i llegeix què anuncia als seus clients.

La referència del model de xifratge cobreix el mateix terreny com a procediment — què et demana la restauració, què vol dir cada mode d'emmagatzematge per a un compte, a quin flux recórrer quan un dispositiu encara no pot llegir una sessió.