#opg $OPG
A criptografia parecia completa para mim até eu fazer uma pergunta um pouco desconfortável:
Criptografado para quem?
Uma mensagem pode estar perfeitamente selada e ainda assim ser entregue à máquina errada. Se eu aceitar qualquer chave pública que um servidor me der, estou protegendo o prompt em trânsito sem provar quem pode abri-lo.
Esse é o detalhe dentro do OpenGradient Chat que quase passei batido.
Antes que chat.opengradient.ai criptografe um pedido privado, o cliente verifica o enclave primeiro.
Ele verifica se a atestação de hardware veio da infraestrutura genuína da AWS Nitro. Compara as medições de PCR da máquina com a construção aprovada registrada no registro TEE do OpenGradient. Também confirma que a chave de criptografia foi criada dentro daquele exato enclave, em vez de ser silenciosamente substituída fora dele.
Só depois que essas verificações passam é que o prompt é selado.
A ordem mudou a forma como penso sobre "criptografia de ponta a ponta".
A criptografia sozinha diz que os externos não podem ler a mensagem.
A atestação pergunta se o receptor pretendido está realmente rodando o software que afirma estar rodando.
Essa segunda pergunta importa porque uma conexão segura com código alterado ainda é uma conexão segura com código alterado.
@OpenGradient está fazendo o cliente verificar o destino antes de confiar no cadeado. O SDK lida com as verificações difíceis de forma silenciosa, mas o usuário se beneficia do resultado: uma construção não aprovada não deve receber o prompt sensível de jeito nenhum.
Para mim, isso é mais forte do que outro ícone de cadeado.
Você prefere confiar apenas na criptografia ou ter seu dispositivo verificando a máquina antes de enviar qualquer coisa?
Esta é a infraestrutura oculta que dá a $OPG um verdadeiro contexto de produto.
A criptografia parecia completa para mim até eu fazer uma pergunta um pouco desconfortável:
Criptografado para quem?
Uma mensagem pode estar perfeitamente selada e ainda assim ser entregue à máquina errada. Se eu aceitar qualquer chave pública que um servidor me der, estou protegendo o prompt em trânsito sem provar quem pode abri-lo.
Esse é o detalhe dentro do OpenGradient Chat que quase passei batido.
Antes que chat.opengradient.ai criptografe um pedido privado, o cliente verifica o enclave primeiro.
Ele verifica se a atestação de hardware veio da infraestrutura genuína da AWS Nitro. Compara as medições de PCR da máquina com a construção aprovada registrada no registro TEE do OpenGradient. Também confirma que a chave de criptografia foi criada dentro daquele exato enclave, em vez de ser silenciosamente substituída fora dele.
Só depois que essas verificações passam é que o prompt é selado.
A ordem mudou a forma como penso sobre "criptografia de ponta a ponta".
A criptografia sozinha diz que os externos não podem ler a mensagem.
A atestação pergunta se o receptor pretendido está realmente rodando o software que afirma estar rodando.
Essa segunda pergunta importa porque uma conexão segura com código alterado ainda é uma conexão segura com código alterado.
@OpenGradient está fazendo o cliente verificar o destino antes de confiar no cadeado. O SDK lida com as verificações difíceis de forma silenciosa, mas o usuário se beneficia do resultado: uma construção não aprovada não deve receber o prompt sensível de jeito nenhum.
Para mim, isso é mais forte do que outro ícone de cadeado.
Você prefere confiar apenas na criptografia ou ter seu dispositivo verificando a máquina antes de enviar qualquer coisa?
Esta é a infraestrutura oculta que dá a $OPG um verdadeiro contexto de produto.