Última atualização: 5 de outubro de 2026 · estado legível por máquina
Esta página descreve o modelo real de segurança da Linka e seus limites atuais. Criptografia é uma propriedade técnica específica, não um adjetivo geral: diferentes fluxos têm fronteiras de confiança diferentes.
A criptografia de mensagens humanas é executada no cliente. O caminho clássico v3 usa ECDH P-256, HKDF-SHA256, AES-256-GCM e uma chave privada Web Crypto não extraível. Ele permanece necessário para estados e histórico compatíveis, mas sua existência não significa autorização para novas mensagens: o código atual exige v5 para mensagens humanas 1:1 por padrão no ambiente Render. O caminho híbrido Android está descrito abaixo.
A identidade pública do contato é fixada localmente e registrada num diretório de Key Transparency append-only. Sessões atuais usam um Double Ratchet versionado para evoluir chaves por mensagem e prekeys descartáveis por aparelho. Se a continuidade de identidade deixa de ser demonstrável, a Linka interrompe o envio protegido; mensagens humanas novas não fazem downgrade silencioso para texto legível pelo servidor.
O caminho implementado de mídia do chat 1:1 cifra fotos, vídeos, áudios e arquivos no aparelho antes do upload. A cobertura de mídia em grupos e dos contratos de salvamento exige verificação própria; não decorre do marco de texto. O armazenamento de mídia recebe um objeto opaco, sem a chave necessária para interpretar o conteúdo. Mídias públicas de posts seguem outro fluxo porque precisam ser exibidas publicamente e transformadas para diferentes telas.
O caminho E2EE v5 para Android combina X25519 e ML-KEM-768; a conversa evolui um Double Ratchet clássico e o SPQR 1.5.3 publicado pelo Signal em paralelo, combinando as duas message keys com separação de domínio antes de AES-256-GCM. O material secreto e o estado do ratchet permanecem num provedor Rust; uma chave AES não exportável do Android Keystore sela o estado persistente.
O servidor guarda bundles públicos, envelopes opacos, recibos e checkpoints do witness. Inscrição, vínculo ao aparelho e hashes dos bundles são verificados. Quando o corte v5 está ativo, um navegador ou aparelho sem provedor compatível não pode enviar usando v3 como atalho. Transporte, notificação legível e rótulo de versão não provam, isoladamente, a abertura da mensagem no chat.
Android 150 / 2.0.50 foi observado Available to selected testers no Alpha, rollout 100%, em 178 de 178 países/regiões, numa consulta datada de 02/10/2026. A distribuição não prova sozinha o funcionamento de cada fluxo. O registro histórico de retomada JNI em Android emulado, sem apagar dados, conserva seu escopo de teste isolado.
Grupos usam OpenMLS 0.9.0 e uma suíte híbrida experimental. O estado local MLS e Shell compartilha uma fronteira transacional; a aceitação no transporte e a aplicação em outro participante continuam fatos distintos. Não se anuncia interoperabilidade universal MLS nem atomicidade distribuída.
Em 01/10/2026, texto nos dois sentidos entre BlueStacks e Samsung alcançou verificado ponta a ponta no cenário documentado: envio, persistência e abertura correlacionados. O proprietário confirmou a observação no Samsung; o agente observou posteriormente BlueStacks e os registros do servidor. Isso não prova todos os grupos, mídia, sucessão geral R7, healing ou rajadas de cliques. Marco e limites.
Na frente formal, a cadeia EasyCrypt fixada aceitou T1 provider-neutral condicional e T2 de continuidade local autenticada. T1 soma as vantagens do provider, exporter e combiner sob projeção, autoridade, desafio e composição explícitos. T2 separa replay, avanço, rollback e fork; rollback e fork falham fechados. Estado: teste isolado passou. A instanciação concreta OpenMLS/TTKEM/KZ, o levantamento QPT, consenso global e Witness independente continuam abertos.
A prévia nativa de push usa um canal auxiliar clássico P-256/HKDF/AES, distinto do envelope Triple Ratchet. Mensagem legível na notificação não é prova de abertura v5 no chat. As chamadas abaixo também não são anunciadas como mídia pós-quântica.
Chamadas usam WebRTC. Na topologia P2P/TURN atual, a mídia trafega por DTLS-SRTP. A negociação vincula call_id, participantes, aparelhos, offer, answer e fingerprints DTLS a uma autorização fresca entregue pela sessão Double Ratchet; a identidade do aparelho é verificada pelo diretório de Key Transparency.
Verificado ponta a ponta · cenário desktop delimitado
Em 6 de setembro de 2026, uma chamada de vídeo entre Uai e TV Test e uma chamada de voz entre Uai, TV Test e Pilar foram observadas em produção. Nos clientes exercitados, identity_authenticated, ratchet_bound, key_transparency_verified, transport_protected e media_received ficaram verdadeiros; áudio e vídeo chegaram aos destinos, e o servidor correlacionou o diretório de aparelhos, as reservas de pré-chave exclusivas da chamada e o encerramento.
Na topologia exercitada — mesh P2P ou TURN como relay sem terminar SRTP — essa composição constitui E2EE de mídia com identidade vinculada para os endpoints observados. O alcance não inclui Android ou iOS físicos, câmera e microfone físicos no lado automatizado, escala, ocultação de IP em conexão P2P, auditoria criptográfica independente, segurança pós-quântica ou uma futura SFU. Se uma SFU vier a terminar a mídia, a fronteira muda e exigirá SFrame ou mecanismo equivalente, nova análise e nova prova ponta a ponta.
A tradução de mensagens protegidas acontece depois da decriptação e no dispositivo de quem lê. No Android, ela usa modelos locais do ML Kit; no navegador, usa motores locais disponíveis. O texto original continua preservado, e o servidor não precisa receber uma cópia em claro só para traduzir.
O chat entre pessoas permanece separado da DAMA. A Linka não envia silenciosamente o histórico E2EE ao modelo. Só o que os participantes escrevem dentro da interface compartilhada da DAMA é selecionado para inferência.
Antes de chamar o fornecedor, a Linka remove identificadores de conta e conversa, representa participantes por máscaras, reduz entidades pessoais detectáveis, minimiza o contexto e faz a conexão sair do backend da Linka. As chamadas atuais usam store=false. O fornecedor ainda processa o texto necessário para gerar a resposta e pode aplicar suas próprias regras operacionais e de segurança. Portanto, o fluxo de IA não é chamado de E2EE nem de anonimato absoluto.
Além das verificações no backend, tabelas privadas usam PostgreSQL Row-Level Security. Transações autenticadas assumem uma role de aplicação sem BYPASSRLS e recebem a identidade do usuário apenas no escopo da transação. O banco pode recusar uma linha mesmo se uma consulta da aplicação estiver incorreta.
Tokens de sessão são valores opacos gerados aleatoriamente; o servidor guarda seu hash e permite expiração ou revogação. Há confirmação de e-mail, redefinição de senha e TOTP opcional.
O Shell é a constituição técnica ativa e versionada da Linka. Gabriel é um sistema de assurance e admissão: relaciona direitos, propriedades, mecanismos substituíveis, superfícies e probes; bloqueia um build quando perde a cobertura que sabe verificar. Não é cifra, firewall nem auditor independente, e não torna completo um contrato que foi formalizado de modo incompleto.
Os artefatos reproduzíveis, fingerprints, SBOM, checksums e não-alegações de cada release ficam no portal público de evidências.
A aplicação usa CSP, Permissions-Policy, HSTS e outros cabeçalhos defensivos. Dados duráveis ficam no PostgreSQL; réplicas de aplicação não dependem do disco local. Redis/Valkey coordena presença, limites globais, eventos em tempo real e tarefas únicas. Sentry e um monitor interno acompanham falhas, latência, memória, entrega de push e disponibilidade da coordenação distribuída usando métricas agregadas.
last_resort, não um estoque de one-time prekeys pós-quânticas;Segurança também é deixar a porta certa aberta.
Se você encontrou uma falha na Linka, queremos saber.
Pesquisadores podem reportar vulnerabilidades em /.well-known/security.txt (RFC 9116) ou pelo endereço safety@linkanetwork.app.
O VDP inicial cobre a superfície pública controlada pela Linka: o domínio linkanetwork.app, fluxos públicos de autenticação, recuperação, sessões e autorização de dispositivos, APIs e WebSockets usados pelo cliente, e o aplicativo Android oficial quando o teste usa somente contas, aparelhos e dados controlados pelo próprio pesquisador.
Pesquisa de boa-fé dentro desse escopo é bem-vinda. A Linka pede que o teste pare se aparecerem dados de terceiros; que não haja indisponibilidade, carga deliberada, engenharia social, persistência, credential stuffing ou expansão de acesso além do mínimo necessário para demonstrar a falha. O reporte deve conter apenas a evidência necessária para reprodução, sem credenciais, chaves privadas, plaintext de mensagens de terceiros ou dumps de banco.
Esta política não autoriza testes intrusivos em produção. Prefira contas e dados sintéticos sob seu controle; se encontrar dados de terceiros, interrompa a investigação e reporte o mínimo necessário para reprodução.
Dentro dessas regras, a Linka pretende tratar a atividade como pesquisa de segurança autorizada e trabalhar para uma resolução coordenada. Esta política não autoriza violar direitos de terceiros nem substitui a legislação aplicável. O programa atual não promete recompensa financeira.
O programa de divulgação de vulnerabilidades é um canal de pesquisa e divulgação coordenada. Não é certificação, pentest concluído, auditoria criptográfica independente nem garantia de ausência de vulnerabilidades.
O que é a Linka: produto, arquitetura e maturidade
Shell: constituição técnica e gate Gabriel
Política de Privacidade
Termos de Uso
Padrões de Segurança Infantil
Ajuda & Suporte