Raiz estatal da internet

A forma como os dados obtêm seu significado define a estrutura da Internet. Dados são algo infinitamente maquiáveis. Você pode simplesmente inventar alguns dados. “123aiab” é um exemplo. Outra é “Barry tem 1 bilhão de seguidores no Twitter”. Mas o que torna os dados significativos é de onde eles vêm. Se o Twitter criar algo sobre meus seguidores no Twitter, isso será muito mais significativo.

“Os dados querem ser gratuitos, mas também querem ser caros”

TLS é um protocolo de criptografia que foi desenvolvido nos primeiros dias do eBay principalmente para permitir a transferência de números de cartão de crédito por meio de uma conexão criptografada. Desde então, tornou-se a criptografia padrão do navegador. Tudo o que você obtém por meio de uma conexão https é via TLS.

Uma importante decisão de design foi que ele não tinha chave privada. Existe uma chave compartilhada, o que significa que o usuário pode fingir que alguns dados vieram de um servidor. Eles assinam os dados e parece que o servidor os assinou.

Isso definiu toda interação como sendo entre usuários e servidores. Qualquer comunicação fora deste relacionamento não tinha sentido.

Uma abordagem é usar o notário TLS, que usa um mpc para calcular a chave compartilhada, de modo que a chave compartilhada seja conhecida pelo servidor, pelo usuário e pelo notário em conjunto. O notário pode saber se determinado dado foi assinado pelo servidor caso este não o tenha assinado. Porque o usuário não consegue assinar sem a ajuda do notário.

A desvantagem dessa abordagem é que custa muito (largura de banda, tempo, complexidade) fazer TLS dentro do mpc. Uma versão mais simples é que o notário poderia possuir a chave compartilhada completa e o usuário não possuir nenhuma dela. O notário ainda pode saber se algo foi assinado pelo servidor, caso o notário não tenha assinado.

A grande desvantagem dessa abordagem é que os dados de todas as solicitações vazam para o servidor. Por exemplo, no caso de uso em que nos preocupamos com a chave da API para várias APIs da web, ela seria conhecida pelo notário. Isso parece bom porque essas chaves de API podem ter taxa limitada e expirar facilmente após serem usadas. A vantagem é que não há necessidade de protocolos mpc complexos. Tudo pode acontecer fora da criptografia, o que significa que é possível autenticar textos, mas também imagens e vídeos.

Agora posso acessar APIs públicas e autenticá-las pelo servidor. Portanto, uma única pessoa precisa acessar os dados de todos os servidores online e então as cópias autenticadas podem ser compartilhadas ponto a ponto. Isso reduz drasticamente o custo de servir a API. Isso também torna a API muito mais escalonável e confiável.

Também altera a topologia da Internet. Permitindo aplicativos muito mais complicados e eliminando o custo de fazer muitas consultas de API com a capacidade de baixar dados autenticados p2p.

Esta é uma maneira simples de tornar os dados do web2 portáteis.

Esta não é uma raiz de estado no sentido tradicional, onde há dados com hash em uma árvore merkle. Mas em espírito é o mesmo conjunto de dados que tem alguma garantia de estar correto. Neste desenho atual, pressupõe-se que o notário é honesto.

O objetivo final desta direção de trabalho é fazer com que os usuários ou o servidor assinem os dados e isso seria o reconhecimento de firma. Isso ainda não chegou, então vamos seguir este passo para construir o restante das peças.

Outra abordagem é usar o IO como notário e então não há suposição de confiança.

No apêndice mostramos como isso pode ser expandido em Tera bytes de dados para serem autenticados. A limitação do reconhecimento de firma dos dados é a quantidade de dados que o usuário pode baixar. Isto abre a questão de como organizamos, armazenamos e distribuímos todos esses dados. Algo algo p2p algo incentivo algo algo outro post.

Parece fácil bifurcar requests.py

1. Substitua a parte https por uma parte que faça com que o notário gere a chave compartilhada. 2. Crie uma maneira de descriptografar os dados e o servidor enviará em troca.
2. Algoritmo simples de reconhecimento de firma

        if did_i_sign_it(x):
            print("I won't notarize this cos i signed it, So it didn't come from server")
        else:
            out = notarize(data)
            return(out)

Então autenticar os dados é tão simples quanto importar solicitações diferentes para o seu script python.

Nota: Na verdade, reqests.py depende de urllib3 para https, então seria necessário fazer um fork e alterá-lo.

Digamos que queremos autenticar alguns dados para a API do Twitter

import requests

# Your credentials
BEARER_TOKEN = "YOUR_BEARER_TOKEN_HERE"
USERNAME = "TwitterDev"

# 1. Get the User ID
user_url = f"https://api.twitter.com/2/users/by/username/{USERNAME}"
user_headers = {"Authorization": f"Bearer {BEARER_TOKEN}"}
user_resp = requests.get(user_url, headers=user_headers)
user_id = user_resp.json()('data')('id')
print(f"User ID for {USERNAME} is {user_id}")

# 2. Get the User's Tweets
tweets_url = f"https://api.twitter.com/2/users/{user_id}/tweets"
tweets_params = {"max_results": 10}
tweets_resp = requests.get(tweets_url, headers=user_headers, params=tweets_params)

# 3. Print the Tweets
tweets = tweets_resp.json()
for tweet in tweets('data'):
    print(f"- {tweet('text')}")

Precisaríamos substituir requests por requests_notary e então o script deveria ser executado como antes. Provavelmente precisaríamos permitir que o usuário baixe as assinaturas autenticadas. Talvez possamos incluir isso como parte do json retornado.

Há uma nuance estranha quando digo “assinar” acima. Quando digo assinatura, quero dizer criptografia/descriptografia. A chave compartilhada não permite assinar no sentido tradicional. Mas se você puder criptografar alguns dados de forma que, se você descriptografá-los com a chave compartilhada, obtenha os dados originais, isso prova que você possui a chave compartilhada. Isso é a prova de que o criptografador tinha a chave compartilhada para criptografá-lo e a prova de que o descriptografador tinha a chave compartilhada para descriptografá-lo. Se algum deles não tivesse a chave compartilhada, a saída seria aleatória.

Abusamos desse fato para permitir a assinatura. Mas a limitação é para big data, o notário precisa fazer upload, descriptografar, assinar e baixar esses dados. Isso simplesmente não funciona para big data como um vídeo do YouTube. O notário precisaria fazer o download para ter certeza de que foi realmente assinado pelo servidor. Eles então descriptografariam e autenticariam os dados.

Podemos inverter isso e evitar que o notário tenha que baixar a resposta. Ao custo da aleatoriedade da assinatura durante os ataques. Dependemos do fato de que apenas alguém que conhece a chave compartilhada pode descriptografar os dados de forma diferente da aleatoriedade. Nós

1. O usuário pede ao servidor notarial para autenticar um blob criptografado.
2. O notário verifica se é um blob criptografado. Se não for, eles autenticam.
3. Em seguida, eles publicam a chave compartilhada para o usuário. Assim, o usuário pode descriptografar os dados. Se for descriptografado de forma não aleatória, ele veio do servidor. Porque somente o servidor poderia tê-lo criptografado. Caso contrário, eles obterão aleatoriedade

Então, basicamente, pedimos ao usuário que se comprometa com os dados e somente depois de se comprometer é que o deixamos descriptografá-los.

Lá para o notário não é necessário baixar a resposta para autenticar. Eles podem autenticar com otimismo e publicar a chave compartilhada posteriormente. Contanto que eles estejam bem, autenticando bobagens, o que parece aceitável em alguns contextos, se você quiser autenticar coisas grandes. Como vídeos ou Tera bytes de coisas.