Encriptação de ponta a ponta, com as chaves nos seus próprios dispositivos

Há um segredo na raiz da sua conta, e ele é criado num dispositivo — não emitido por um servidor. Tudo o resto é derivado dele por uma árvore de chaves: uma raiz HMAC-SHA-512, e depois um passo HMAC por cada elemento de caminho etiquetado. O par de chaves que abre as chaves de sessão seladas sai dessa árvore sob a etiqueta "content", e o mesmo acontece a uma chave separada para cada outro tipo de blob guardado, para que nenhuma chave faça dois trabalhos.

É por isto que um navegador acabado de estrear pode iniciar sessão na sua conta e mesmo assim não lhe mostrar nada da semana passada. Iniciar sessão prova ao relay quem você é. Ler uma sessão antiga precisa da chave, e a chave não está no relay para ser enviada. Restaurar o dispositivo é o passo que a move — a partir de um dispositivo que já a tem, ou da chave secreta que guardou.

Significa também que o caso de perda é real e vale a pena ser dito uma vez: se todos os dispositivos com sessão iniciada desaparecerem e a chave secreta desaparecer com eles, as sessões encriptadas não podem ser recuperadas por nós nem por ninguém. Um relay que as pudesse devolver seria um relay que as conseguiria ler.

Adicionar um dispositivo é o momento em que material de chaves se move, por isso é o momento que vale a pena perceber. Ler o código QR levanta um pedido, e é só isso que faz: a aprovação acontece num dispositivo que já tem sessão iniciada, e quando os dois ecrãs mostram um código curto de confirmação é suposto compará-los antes de aprovar.

O que a aprovação faz na prática é selar a chave de conteúdo com a chave pública do dispositivo que pediu, num envelope que transporta uma chave de remetente efémera e um nonce novo. Esse envelope viaja através do relay como tudo o resto. Ligar um terminal acrescenta mais uma amarração por cima: o payload é autenticado contra um segredo de emparelhamento que viajou no código QR, e não através do servidor, por isso um relay que trocasse o payload não conseguiria produzir uma etiqueta correspondente.

Tudo o que está acima descreve a predefinição, e a predefinição não é uma sugestão da qual o cliente possa demover o servidor. Um relay novo está configurado para exigir armazenamento encriptado de ponta a ponta: uma escrita em texto simples é recusada com um erro de política em vez de ser aceite em silêncio. Os clientes leem a política a partir do endpoint de features do próprio servidor antes de criarem uma sessão, por isso o modo em que uma sessão está foi acordado antes da primeira mensagem dela.

Um operador de servidor tem outras duas definições disponíveis. Uma permite que seja uma conta a escolher, para que sessões encriptadas e em texto simples coexistam no mesmo relay — exige tanto a política opcional como a permissão de exclusão, e essa permissão está desligada a menos que o operador a ligue. A outra exige texto simples, para organizações que gerem a encriptação na camada de infraestrutura e precisam de que o servidor consiga ler e processar o conteúdo das sessões. Essa última é uma troca real e vale a pena dizê-lo sem suavizar: numa sessão em texto simples o servidor consegue ler a transcrição. É esse o objetivo da definição.

O modo é fixado por sessão no momento da criação, por isso uma sessão nunca é metade de cada, e mudar o modo de uma conta muda o que acontece às sessões novas em vez de mexer nas antigas. Nada é desencriptado retroativamente, e nada é encriptado retroativamente também.

As variáveis que definem as três, as opções de armazenamento por baixo delas e os controlos de identidade à volta delas são a metade do operador, e vivem na página de auto-alojamento para equipas.

Uma notificação push é a única coisa que sai do modelo, porque tem de chegar a um telemóvel que não tem nada aberto. A resposta do Happier é que é o seu próprio computador que as envia. O servidor guarda os seus tokens push; a CLI no seu próprio computador lê-os de volta e envia ela mesma a notificação, o que mantém o relay fora de um caminho em que, de outra forma, teria de lhe ser dito o conteúdo.

O que o payload transporta é deliberadamente magro: o tipo de ferramenta ou de pedido, e uma dica curta quando ajuda — um ficheiro como src/file.ts, o nome de um comando, uma contagem como "3 perguntas". A entrada em bruto das ferramentas não é colocada lá. O suficiente para decidir se vale a pena pegar no telemóvel, num ecrã que qualquer pessoa atrás de si consegue ler.

Tudo isto se mantém num relay que não é você a correr. A razão para correr o seu próprio é a linha acima sobre identificadores e forma: a encriptação não esconde quem fala com quem, nem com que frequência, e no seu próprio relay esse registo também é seu. Um comando coloca o relay em hardware seu, e o caminho passa a ser o seu dispositivo, o seu relay, o seu computador, sem nada lá dentro que não tenha sido você a instalar.

Não há nenhuma certificação nesta página porque não há nenhuma para reportar, e uma página de segurança que acena a conformidade que não tem é pior do que uma que não a menciona. O que está aqui em vez disso é o código a partir do qual todas as frases acima foram escritas, com licença MIT e legível antes de o correr: as primitivas em packages/protocol/src/crypto, a encriptação de sessão em apps/cli/src/api/encryption.ts, a política de armazenamento que o servidor impõe no seu endpoint de features, e o esquema que mostra exatamente que colunas estão em texto simples.

Essa é também a resposta honesta a como deve tratar esta página: como um mapa de onde procurar, não como uma promessa a aceitar em confiança. Leia os quatro ficheiros, ou corra o relay você mesmo e leia o que ele anuncia aos seus clientes.

A referência do modelo de encriptação cobre o mesmo terreno em forma de procedimento — o que o restauro lhe pede, o que cada modo de armazenamento significa para uma conta, e a que fluxo recorrer quando um dispositivo ainda não consegue ler uma sessão.