BitNotíciasBitNotícias
  • Últimas Notícias
  • Mercado
  • Regulação
  • Web3
  • Onde Investir
    • Criptomoedas Promissoras
    • Criptomoedas com Potencial
    • Memecoins
    • Inteligência Artificial
  • Guias
    • Passo a Passo para Iniciantes
    • Melhores Corretoras de Criptomoedas
    • Melhores Carteiras de Criptomoedas
    • Melhores Cartões Cripto
    • Comprar Criptomoedas
  • Análises
    • Cartões
    • Carteiras
    • Corretoras
Você está lendo: O Evangelho de Satoshi Nakamoto – Cap. 34 vers. 4
Compartilhe
BitNotíciasBitNotícias
Pesquise:
  • Últimas Notícias
  • Mercado
  • Regulação
  • Web3
  • Onde Investir
    • Criptomoedas Promissoras
    • Criptomoedas com Potencial
    • Memecoins
    • Inteligência Artificial
  • Guias
    • Passo a Passo para Iniciantes
    • Melhores Corretoras de Criptomoedas
    • Melhores Carteiras de Criptomoedas
    • Melhores Cartões Cripto
    • Comprar Criptomoedas
  • Análises
    • Cartões
    • Carteiras
    • Corretoras
BitNotícias nas Redes:
© 2019 – 2024 BitNotícias. Todos os direitos reservado
BitNotícias > Notícias > O Evangelho de Satoshi Nakamoto – Cap. 34 vers. 4
Notícias

O Evangelho de Satoshi Nakamoto – Cap. 34 vers. 4

Por Leonardo Broering Jahn
Atualizado em: 07/01/2025
Compartilhe
Compartilhe

Boa noite povo!

Vimos, no versículo anterior, a terceira parte da tradução de “Hashcash – A Denial of Service Counter-Measure”, continuamos hoje com a parte 4.

CONTINUA APÓS A PUBLICIDADE

4 Hashcash Interativo

Com a forma interativa do hashcash, para uso em configurações interativas tais como o estabelecimento de conexões TCP, TLS, SSH, IPSEC, etc, um desafio é escolhido pelo servidor. O objetivo do hashcash interativo é defender os recursos do servidor de esgotamento prematuro, e prover uma degradação graciosa do serviço com alocação justa entre usuários em face a um ataque DoS onde um usuário tenta negar serviço a outros usuários consumindo tanto recurso do servidor quanto ele puder. No caso de protocolos de segurança tais como TLS, SSH e IPSEC com fases de estabelecimento de conexões caras computacionalmente envolvendo criptografia de chave pública, o recurso do servidor sendo defendido é o tempo de CPU disponível.

A função-custo do hashcash interativo é definida como segue:

4.1 Restrição Dinâmica

CONTINUA APÓS A PUBLICIDADE

Com o hashcash interativo se torna possível ajustar dinamicamente o fator de trabalho requerido por um cliente baseado na carga de CPU do servidor. A abordagem também admite a possibilidade de que a resposta ao desafio do hashcash interativo seja usada apenas durante períodos de alta carga. Isso torna possível a introdução gradual de protocolos resistentes ao DoS sem interromper a compatibilidade retroativa com o software cliente antigo. Em períodos de alta carga os clientes que não usam hashcash não conseguiriam conectar, ou seriam colocados em uma pool de conexão limitada sujeitos a contramedidas para DoS antigas e menos efetivas como quedas aleatórias de conexão.

4.2 Cookies-hashcash

Com ataques de esgotamento do slot de conexão, como o ataque syn-flood [de inundação de sincronização], e o esgotamento direto do slot de conexão TCP, o recurso do servidor que está sendo consumido é o espaço disponível para o stack [pilha] TCP para armazenar o estado por conexão.  

CONTINUA APÓS A PUBLICIDADE

Nesse cenário pode ser desejável evitar manter o estado por conexão, até que o cliente tenha computado um token com a função-custo do hashcash interativo. Essa defesa é similar à defesa syn-cookie ao ataque syn-flood, mas aqui propomos a impor adicionalmente um custo de CPU na máquina de conexão para reservar um slot de conexão TCP.

Para evitar o armazenamento do desafio no estado da conexão (que consome espaço), o servidor pode optar por calcular uma MAC [autenticador de mensagem, na sigla em inglês] com chave das informações que, de outra forma, armazenaria e as enviaria ao cliente como parte do desafio, para ele poder verificar a autenticidade do desafio e o token quando o cliente os retorna. (Essa técnica geral – de enviar um registro que você armazenaria junto com uma MAC à entidade sobre a qual a informação se refere – é referido como certificado de chave simétrica.) Essa abordagem é análoga à técnica usada na syn-cookies, e Jules e Brainard propuseram uma abordagem relacionada, mas no nível do protocolo de aplicação, em seu artigo sobre quebra-cabeças de clientes. 

Por exemplo, com a função MAC M com a chave K do servidor o desafio MAC poderia ser computado como:

CONTINUA APÓS A PUBLICIDADE

O cliente deve mandar o m da MAC, e o desafio c e os parâmetros do desafio p com o token de resposta para que o servidor possa verificar o desafio e a resposta. O servidor deve também incluir na MAC os parâmetros da conexão, no mínimo o suficiente para identificar o slot de conexão e alguma medida de tempo ou aumento do contador t para que respostas antigas de desafio não possam ser coletadas e reutilizadas depois que os slots de conexão estiverem livres. O desafio e a MAC seriam enviados na mensagem de resposta TCP SYN-ACK e o cliente incluiria o token do hashcash interativo (resposta do desafio) na mensagem TCP ACK. Assim como com os syn-cookies, o servidor não precisaria manter nenhum estado por conexão antes de receber o TCP ACK. 

Para compatibilidade com versões anteriores com pilhas TCP com reconhecimento de syn-cookies, uma pilha TCP com reconhecimento de cookie-hashcash apenas ativaria os cookies-hashcash quando detectasse que estivesse sujeito a um ataque de esgotamento de conexão TCP. Argumentos semelhantes como dados por Dan Bernstein em [5] pode ser usados para mostrar que a compatibilidade com versões anteriores é mantida, isso é, sob ataques syn-flood, os argumentos de Bernstein mostram como prover compatibilidade retroativa com implementações que não reconhecem syn-cookies; similarmente sob um ataque de esgotamento de conexão os cookies-hashcash são apenas ativados em um momento em que, caso contrário, o serviço não estaria disponível de qualquer forma para uma pilha TCP que não reconhece cookies-hashcash.

A medida em que o flood aumenta em gravidade, o algoritmo do cookie-hashcash aumentaria o tamanho da colisão necessária para estar na mensagem TCP ACK. O cliente com reconhecimento de cookie-hashcash ainda pode se conectar (embora cada vez mais devagar) com uma chance mais justa contra o atacante DoS, presumindo que o DoSer tenha recursos de CPU limitados. O atacante DoS vai efetivamente estar colocando seu CPU contra todos os outros clientes (que reconhecem os cookies-hashcash) também tentando conectar. Sem a defesa do cookie-hashcash o DoSer pode floodar [inundar] o servidor  com estabelecimentos de conexão e pode mais facilmente amarrar todos seus slots concluindo n conexões por tempo limite de conexão inativa em que n é o tamanho da tabela de conexões, ou fazendo ping das conexões uma vez que o tempo limite de conexão inativa seja atingido para convencer o servidor de que elas estão vivas.

CONTINUA APÓS A PUBLICIDADE

As conexões serão entregues aos usuários coletivamente na proporção aproximada de seus recursos de CPU, então a justiça é baseada nos recursos de CPU (presumindo-se que cada usuário estaria tentando abrir quantas conexões fossem possíveis), então o resultado será enviesado a favor dos clientes com processadores velozes já que eles podem computar mais tokens de resposta do desafio do hashcash interativo por segundo.

[5]  Dan Bernstein. Syn cookies. Publicado em http://cr.yp.to/syncookies.html.

Vista a quarta parte, no versículo seguinte a quinta. Abraços!

Fairshake lidera financiamento político com foco em cripto nas eleições dos Estados Unidos
MARA aposta em rendimento com Bitcoin ao adquirir participação na Two Prime
Standard Chartered lança negociação direta de Bitcoin e Ether para investidores institucionais
Arcadia Finance sofre ataque hacker e perde mais de US$ 3 milhões em criptomoedas
Paxos e OKX firmam parceria para expandir uso global do USDG
TagsAdam BackSatoshi Nakamoto
Compartilhe este artigo
Facebook Whatsapp Whatsapp Telegram Copiar Link
PorLeonardo Broering Jahn
@leonardobjahn Natural de Florianópolis, SC 27 anos Evangelista Bitcoin Graduando Administração na UFSC Professor particular e tradutor de Inglês
Publicidade

Últimas Notícias

SharpLink vira referência com o maior estoque de Ethereum do setor
SharpLink vira referência com o maior estoque de Ethereum do setor
2 min
BONK pode disparar 37% após saída de US$ 16 milhões em tokens exchanges
BONK pode disparar 37% após saída de US$ 16 milhões em tokens exchanges
3 min
Stellar (XLM) salta 72% com stablecoin do PayPal
Stellar (XLM) salta 72% com stablecoin do PayPal
3 min

Destaque

  • Últimas Notícias
  • Mercado
  • Regulação
  • Tecnologia
  • Web3
  • Eventos

Reviews

  • Cartões
  • Wallets
  • Exchanges

Guias

  • Investir Agora
  • Comprar Criptomoedas
  • Melhores Corretoras
  • Carteira de Criptomoedas
  • Cartões de Criptomoedas
  • Glossário

Tudo Sobre

  • Bitcoin
  • Ethereum
  • Polygon
  • Solana
  • Mineração
  • Web3

Sobre Nós

  • MediaKit
  • Quem Somos
  • Política Editorial
  • Política de Privacidade
  • Política de Cookies
  • Contato
Cookie Settings
BitNotícias nas Redes:
© 2019 – 2024 BitNotícias. Todos os direitos reservado
Welcome Back!

Sign in to your account

Username or Email Address
Password

Lost your password?