USTP

USTP significa UDP Speedy Transmission Protocol.

O USTP mantém o mesmo modelo de transporte autenticado, mas o nome do projeto agora é simplesmente USTP novamente.

Por padrão, o USTP usa AEAD para DATA.

Ele também suporta um modo opcional negociado de cleartext + HMAC para DATA, no qual os bytes de payload são visíveis na rede, mas a adulteração é detectada e rejeitada.

O USTP agora suporta um controlador de congestionamento opcional chamado USTP Congestion. Ele continua sendo UDP-first, mas pode opcionalmente desacelerar e voltar a acelerar quando o caminho começa a mostrar sinais de congestionamento.

Status: Beta

O USTP não é mais apenas uma prova de conceito. Ele está atualmente na fase Beta.

O USTP pode ser usado para muitos tipos de aplicações e transportes.

Este repositório, no entanto, é focado especificamente em streaming sobre USTP.

Notícias

• 02/08/2026: USTP-Secure agora voltou a ser USTP.
  • USTP-Secure era um nome antigo do projeto e não é mais adequado para ele.
  • O nome mais curto USTP agora é preferido novamente.
  • O nome completo agora é UDP Speedy Transmission Protocol, sem Secure no título.
• 2026-07-18: O USTP/2 Beta foi removido da árvore atual.
  • O comportamento no mundo real era menos estável que o USTP/1.1 sob perda.
  • O caminho de transporte estável atual é apenas o USTP/1.1.
  • O handshake de transporte agora usa registros ASCII em texto claro.

Nota de build

• Construído com Codex usando GPT-5.4 (Low).
• Verificado sem travamentos em --loss 33.
• Caminho de teste: Brazil -> Canada com cerca de 140ms de RTT.

Modelo de segurança

• O transporte continua sendo UDP (sem túnel TCP)
• Cifras AEAD:
  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
• Cifra AEAD padrão: chacha20
• O modo de proteção padrão de DATA é AEAD.
• O modo de proteção opcional de DATA é cleartext + HMAC por pacote.
• No modo cleartext, os bytes de payload não são criptografados, mas modificações são detectadas e pacotes inválidos são descartados.
• Pacotes de controle de transporte (HELLO, ACK, RETRANSMIT_REQUEST, CLOSE) permanecem em texto claro de propósito.
• Pacotes de controle são serializados como registros de transporte ASCII.
• ACK e NACK/RETRANSMIT_REQUEST permanecem em texto claro, mas são autenticados com uma tag HMAC por sessão.
• Isso impede que pacotes de controle ACK/NACK forjados off-path forcem ataques de ACK ou DoS por retransmissão após o estabelecimento da sessão segura.
• Pacotes DATA usam um formato de frame binário chamado UPACK (UPAK na rede).
• Nenhuma PSK estática é usada.
• Cada cliente realiza uma troca de chaves X25519 ao se conectar.
• Cada cliente recebe uma chave de sessão AEAD separada.
• Os servidores suportam múltiplos clientes.
• O servidor valida o cliente com um round-trip de desafio no IP:port de origem.
• Se --cipher for definido no servidor, o servidor usa exatamente essa cifra.
• Se --cipher for omitido ou definido como auto, o servidor usa a cifra solicitada pelo cliente.
• Os clientes rejeitam negociação de cifra inesperada.
• O modo de proteção de DATA é negociado separadamente da escolha de cifra:
  • servidor: --cleartext auto|on|off
  • cliente: --cleartext on|off
  • padrão do servidor: auto
  • padrão do cliente: off
• Com o servidor em auto, o servidor segue a solicitação do cliente.
• Com o servidor em on, o servidor força cleartext + HMAC.
• Com o servidor em off, o servidor força AEAD.
• TOFU (Trust On First Use) está habilitado no cliente para detectar mudanças inesperadas na chave do servidor após a primeira conexão.
• O servidor mantém uma chave de host X25519 persistente em ~/.ustps_host_key por padrão, para que o TOFU permaneça estável entre reconexões e reinicializações.
• Um reinício normal do servidor não altera a chave de host.
• Use --regen-key no servidor apenas quando você quiser intencionalmente rotacionar essa chave de host.

Valores mágicos dos pacotes

• ACK:, NACK:, HELLO: e CLOSE: são os prefixos dos registros de controle em texto simples.
• USS1 significa UDP Speedy Secure, versão 1.
• USC1 significa UDP Speedy Clear, versão 1.
• UPAK é o marcador binário do frame DATA UPACK.
• No USTP, o controle em texto simples é ASCII legível por humanos, como ACK: 10, NACK: 42, HELLO: ... e CLOSE:.
• No USTP, UPAK identifica pacotes DATA binários após a descriptografia.
• No USTP, USS1 é o formato do envelope AEAD seguro externo.
• No USTP, USC1 é o formato do envelope DATA externo em texto claro+HMAC.
• Assim, no tráfego de rede você normalmente vê:
  • USS1... para DATA protegido por AEAD
  • USC1... para DATA em texto claro+HMAC
  • linhas de controle legíveis para controle de transporte

Modelo de transporte

• O USTP pode operar com USTP Congestion opcional, negociado durante o handshake.
• Os pacotes carregam tanto um seq de transporte quanto um stream_pos voltado à aplicação.
• seq é usado para ACK, detecção de perda, retransmissão e amostragem de RTT.
• stream_pos informa à aplicação onde o payload pertence no fluxo lógico de bytes.
• Na implementação atual, seq é um contador de 32 bits que começa em 1 para cada nova sessão.
• Na implementação atual, stream_pos é um contador de bytes de 64 bits que começa em 0 para cada novo fluxo lógico.
• O receptor aceita pacotes imediatamente em vez de bloquear a entrega atrás de um pacote ausente.

Modelo de handshake e sessão

• O cliente começa com um HELLO de transporte em texto simples, carregando sua chave pública X25519, a cifra solicitada, o modo de controle de congestionamento solicitado (on ou off) e o modo de proteção de DATA solicitado (cleartext on|off).
• O servidor não envia mídia imediatamente. Ele primeiro envia um desafio em texto simples contendo:
  • um token de retry aleatório
  • um session_id gerado em Base64
  • a cifra selecionada
  • o modo de controle de congestionamento negociado
  • o modo de proteção de DATA negociado
  • a chave pública do servidor
• O cliente deve responder com exatamente o mesmo token e os mesmos metadados de sessão.
• Somente após esse round-trip do token ser bem-sucedido o servidor cria a sessão e começa a enviar DATA.
• Após a validação, a sessão é vinculada ao IP:port de origem que completou o desafio.
• session_id ainda é usado como rótulo de sessão, mas não é aceito a partir de um IP:port diferente.

Token de Retry

• O USTP usa uma etapa de token de retry em texto simples antes que qualquer sessão de mídia criptografada seja aceita.
• Fluxo:
  • o cliente envia HELLO
  • o servidor responde com USTPS-CHALLENGE1 carregando token, session_id, cifra selecionada, modo de controle de congestionamento negociado, modo de proteção de DATA negociado e chave pública do servidor
  • o cliente ecoa esse token de volta em USTPS-CHALLENGE-REPLY1
  • somente então o servidor cria a sessão e envia USTPS-SESSION1
• Propósito:
  • provar que o remetente naquele IP:port de origem consegue realmente receber pacotes ali
  • evitar enviar mídia criptografada imediatamente para um endereço de origem não validado
  • vincular a criação final da sessão ao endpoint que completou o round-trip
• O token de retry não é a chave de sessão.
• Ele é apenas uma prova de alcançabilidade e uma barreira de handshake antes que a sessão USTP real seja criada.
• Ele também não é usado como nonce, não é usado por si só como chave MAC de ACK/NACK e não é reutilizado como estado de payload de pacote.