Criptografia pós-quântica on Arpokrat

Data Act vs CLOUD Act: quem controla realmente os seus dados na cloud?

Fri, 19 Jun 2026 00:00:00 +0000

Durante anos, o mundo funcionou com base numa hipótese simples: os dados têm um local de residência físico. Se estivessem num servidor em Dublin, estavam sujeitos ao direito irlandês e europeu. Esta hipótese ruiu em 2018, quando os Estados Unidos adotaram o CLOUD Act, uma lei que confere às autoridades americanas acesso aos dados controlados por empresas americanas, independentemente do local onde esses dados estejam fisicamente armazenados no mundo. Vários anos depois, Bruxelas respondeu com o seu próprio mecanismo de proteção: o Data Act, agora plenamente aplicável, que tenta limitar o acesso extraterritorial de autoridades de países terceiros aos dados detidos na União Europeia.

Eis o que estes dois textos preveem na realidade, onde entram em colisão, e por que razão a única proteção verdadeiramente robusta face a este conflito continua a ser a impossibilidade técnica de acesso.

O CLOUD Act americano: um acesso baseado no controlo, não na localização

O CLOUD Act (Clarifying Lawful Overseas Use of Data Act), adotado em março de 2018, alterou o direito americano ao introduzir o artigo 18 U.S. Code § 2713. Este texto impõe a qualquer prestador de serviços de comunicação eletrónica ou de computação remota que preserve, salvaguarde ou divulgue o conteúdo de uma comunicação ou qualquer registo a ela relacionado, desde que esses dados estejam na sua posse, à sua guarda ou sob o seu controlo, independentemente de esses dados se encontrarem dentro ou fora dos Estados Unidos.

É precisamente esta última cláusula que muda tudo. O critério adotado já não é a localização física do servidor, mas o controlo exercido pela empresa-mãe sobre as suas filiais. Uma empresa americana que opera centros de dados na Europa permanece, portanto, sujeita a requisições americanas, mesmo para dados armazenados integralmente em solo europeu.

O Data Act europeu: uma barreira jurídica ao acesso extraterritorial

O Regulamento (UE) 2023/2854, designado Data Act, entrou em vigor a 11 de janeiro de 2024 e aplica-se plenamente desde 12 de setembro de 2025, com algumas disposições escalonadas até 2026 e 2027. O seu artigo 32.º regula diretamente a questão do acesso governamental internacional aos dados.

O texto estabelece uma regra clara: qualquer decisão ou sentença de um tribunal ou autoridade administrativa de um país terceiro que exija a um prestador de serviços de tratamento de dados que transfira ou dê acesso a dados não pessoais detidos na União Europeia só é reconhecida e executória se se basear num acordo internacional, como um tratado de auxílio judiciário mútuo (AJM), em vigor entre o país requerente e a União, ou entre esse país e o Estado-Membro em causa.

Na ausência de tal acordo, o artigo 32.º prevê uma segunda via, mas estritamente enquadrada: a decisão estrangeira só pode ser executada se o sistema jurídico do país terceiro exigir que o pedido seja fundamentado, proporcionado e suficientemente específico — por exemplo, estabelecendo uma ligação clara com pessoas ou infrações precisas — e se a objeção fundamentada do destinatário puder ser submetida ao controlo de um tribunal competente desse país terceiro.

Uma colisão jurídica direta

O problema é imediato: o CLOUD Act exige uma divulgação baseada no controlo exercido pela empresa-mãe, sem uma condição de proporcionalidade comparável à exigida pelo direito europeu. O Data Act, pelo contrário, subordina o reconhecimento de tal pedido à existência de um acordo internacional ou a garantias processuais precisas. Uma empresa americana que opera na Europa, intimada por uma autoridade americana a transmitir dados alojados na União, fica assim presa entre duas obrigações legais contraditórias: conformar-se com o mandato americano violando o direito da União, ou respeitar o Data Act expondo-se às consequências de uma recusa nos Estados Unidos.

Esta tensão não é teórica. Já foi documentada pelo Tribunal de Justiça da União Europeia (TJUE) em duas decisões maiores, Schrems I (2015) e Schrems II (2020). No acórdão Schrems II, o TJUE considerou que a vigilância americana conduzida ao abrigo da Secção 702 do FISA (Foreign Intelligence Surveillance Act) e da Executive Order 12333 não respeita as garantias mínimas exigidas pelo direito da União ao abrigo do princípio da proporcionalidade, e não pode, portanto, ser considerada como limitada ao estritamente necessário. O Tribunal assinalou igualmente a ausência de uma via de recurso jurisdicional efetiva para as pessoas em causa na União, em violação do artigo 47.º da Carta dos Direitos Fundamentais. Esta decisão invalidou o quadro do Privacy Shield, que até então organizava as transferências de dados entre a UE e os Estados Unidos.

O risco estrutural: Harvest Now, Decrypt Later

Para além do conflito de jurisdições, uma ameaça mais insidiosa pesa sobre os dados alojados em infraestruturas sujeitas ao direito americano: a estratégia denominada Harvest Now, Decrypt Later (HNDL). O princípio consiste, para um serviço de informações ou um ator estatal hostil, em intercetar e armazenar hoje dados cifrados, aguardando capacidades de computação quântica suficientes para os decifrar no futuro.

Esta estratégia transforma qualquer dependência prolongada de uma infraestrutura cloud americana numa dívida de segurança diferida: o que é confidencial hoje pode tornar-se legível daqui a dez ou quinze anos, sem que seja necessária qualquer ação adicional por parte do atacante — apenas tempo e paciência.

Por que razão apenas a impossibilidade técnica constitui uma verdadeira garantia

A análise jurídica converge para uma conclusão partilhada por muitos especialistas em conformidade: por mais sólido que seja o quadro legal do Data Act, permanece um texto que as relações de força geopolíticas e as pressões diplomáticas podem contornar, atrasar ou reinterpretar. A única proteção que não depende de nenhuma negociação futura é a impossibilidade técnica de execução.

Uma arquitetura zero knowledge, em que o prestador não detém nem a posse nem a guarda das chaves de decifração, torna uma requisição materialmente inoperante. Não se pode ser obrigado a entregar o que nunca se possuiu.

É esta a lógica que estrutura ecossistemas como o Arpokrat:

Neutralização jurisdicional: a infraestrutura está alojada na Suíça, ao abrigo da lei federal sobre proteção de dados (LPD/FADP), fora do âmbito de aplicação direta da extraterritorialidade do CLOUD Act
Ausência de guarda: a arquitetura zero knowledge priva o prestador de qualquer capacidade para entregar chaves ou conteúdos que nunca detém
Redução da pegada identitária: ao suprimir a obrigação de registo por número de telefone ou endereço de e-mail — identificadores que a vigilância baseada na Secção 702 do FISA pode rastrear facilmente — o utilizador deixa de ser um assinante identificável para se tornar uma chave criptográfica anónima

A cadeia de custódia não termina na cifragem das mensagens

Um ponto frequentemente subestimado nas análises de conformidade: não basta cifrar o conteúdo de uma comunicação se o sistema operativo subjacente — seja Android ou iOS — continua a capturar metadados ou telemetria ao nível do kernel, com destino a servidores sujeitos à jurisdição americana. A proteção do segredo exige um encerramento completo da cadeia de custódia, do conteúdo até à própria infraestrutura de hardware.

É por esta razão que a soberania digital implica também uma reflexão sobre o sistema operativo utilizado, e não apenas sobre as aplicações de mensagens. Sistemas operativos desgoogalizados, onde módulos como o Bluetooth ou a geolocalização GNSS podem ser desativados diretamente ao nível do kernel, eliminam vetores de ataque físicos que nenhuma cifragem aplicativa consegue compensar.

A criptografia pós-quântica, um horizonte já em curso

Face à ameaça representada pela estratégia HNDL, a adoção de standards de criptografia pós-quântica (PQC) torna-se uma necessidade para quem pretenda garantir a confidencialidade de dados sensíveis a longo prazo — sejam segredos comerciais, correspondência profissional ou dados de saúde. Uma cifragem considerada robusta hoje segundo os standards clássicos não garante que resistirá às capacidades de computação quântica esperadas nos próximos quinze anos.

O conflito entre o Data Act e o CLOUD Act ilustra uma realidade mais ampla: a soberania digital já não pode ser construída exclusivamente sobre textos legislativos, por mais sólidos que sejam. Exige um encerramento da cadeia de custódia a cada nível — do protocolo de cifragem até à jurisdição de alojamento, passando pelo próprio sistema operativo. É esta abordagem por camadas, em vez de uma confiança assente num único quadro regulatório, que define hoje uma verdadeira soberania digital por conceção.

Senha e Entropia: A ciência por trás da sua segurança

Wed, 03 Jun 2026 00:00:00 +0000

« Sua senha deve conter 8 caracteres, uma letra maiúscula, uma letra minúscula, um número e um caractere especial. »

Todos conhecemos essa regra. E, no entanto, na segurança cibernética, isso é o que chamamos de “teatro de segurança”. Uma senha como P@ssw0rd1! respeita todas essas regras. Mas é uma palavra comum com substituições previsíveis, exatamente o que as ferramentas de quebra tentam primeiro.

A verdadeira segurança não se baseia em regras visuais arbitrárias, mas em uma realidade matemática implacável: a entropia.

A Entropia segundo Claude Shannon

Para entender a força de uma senha, devemos olhar para Claude Shannon, o pai da teoria da informação. A entropia mede o grau de incerteza ou imprevisibilidade de uma informação.

Aplicada a senhas, a entropia é calculada em bits. Quanto maior o número de bits, mais imprevisível é a senha para um computador. A fórmula simplificada para a entropia (E) de uma senha gerada aleatoriamente é:

E = L × log2(R)

L é o comprimento da senha.
R é o tamanho do conjunto (26 para minúsculas, 62 com maiúsculas e números, 94 com todos os símbolos imprimíveis). Os quatro conjuntos de caracteres do nosso gerador somam 91, porque o seu conjunto de símbolos tem 29 caracteres.

Aumentar o tamanho do conjunto (adicionando símbolos) aumenta a entropia, mas aumentar o comprimento (adicionando caracteres) aumenta-a de forma muito mais drástica. No entanto, o comprimento só vence a complexidade sob uma condição: a senha deve ser gerada de forma completamente aleatória.

Força Bruta vs. Ataque de Dicionário

Se você usar palavras ou estruturas previsíveis, a regra do comprimento puro entra em colapso.

O software de hacking não tenta todas as combinações de letras uma por uma (isso é chamado de Força Bruta). Eles usam enormes listas de senhas reais vazadas em violações de dados anteriores, além de palavras e frases comuns. Este é o Ataque de Dicionário.

Se a sua senha for longa, mas for composta por palavras do dicionário ou substituições previsíveis, sua entropia real é dramaticamente menor do que a entropia matemática teórica.

A tabela abaixo segue uma única regra: 100 bilhões de tentativas por segundo, o ritmo que a página do nosso gerador pressupõe para um ataque offline contra um hash rápido. Os tempos são médias (metade de todas as possibilidades), arredondadas para baixo com a mesma fórmula dessa página. A rota mais rápida para cada senha está em negrito:

Senha	Entropia se cada caractere fosse aleatório	Força bruta (média)	Ataque de dicionário (nossa estimativa)
`password123`	56 bits (11 caracteres, minúsculas e números)	7 dias	Menos de um segundo
`S3cr3t!99`	58 bits (9 caracteres, os quatro conjuntos)	24 dias	Menos de um segundo
`correct horse battery staple`	133 bits (28 caracteres, minúsculas e espaço)	Mais de 1 trilhão de anos	1 minuto
`gL7!pQ9z#vX2`	78 bits (12 caracteres, os quatro conjuntos)	51 mil anos	Nenhum atalho

A coluna de dicionário é uma estimativa. Ela pressupõe que as tentativas do atacante seguem a estrutura de cada senha e que cada palavra-base está entre as 1.000 mais comuns:

password123: uma palavra comum e três dígitos. São 1.000 × 1.000, cerca de um milhão de tentativas.
S3cr3t!99: uma palavra comum, com ou sem maiúscula, cada “e” trocado ou não por “3”, e depois qualquer sufixo de três caracteres. São cerca de 7 bilhões de tentativas.
correct horse battery staple: quatro palavras comuns. A tirinha xkcd que a tornou famosa conta 44 bits para quatro palavras de uma lista de 2.048. No mesmo ritmo, são 88 segundos em média, arredondados para baixo para 1 minuto.
gL7!pQ9z#vX2: nenhuma palavra e nenhum padrão, então a força bruta é a rota mais rápida.

Essas estimativas tratam cada senha como desconhecida pelo atacante. Todas as senhas deste artigo agora são públicas, então cada uma pertence a um dicionário. Uma senha publicada é uma senha queimada.

A Ilusão do Leetspeak e as Regras de Mutação

Vejamos o exemplo S3cr3t!99. Visualmente, parece complexa e robusta. No entanto, é simplesmente a palavra do dicionário “secret”, onde os ’e’s foram substituídos por ‘3’s, à qual foi adicionado um sufixo muito comum (!99). Isso é chamado de leetspeak.

Contra um ataque de dicionário, esta senha resiste menos de um segundo, não os 24 dias que o seu comprimento sugeriria. O software de cracking moderno (como Hashcat) não se contenta em testar listas de palavras estáticas; eles aplicam automaticamente regras de mutação. Eles vão pegar cada palavra do seu dicionário, testar todas as combinações possíveis de leetspeak, inverter as maiúsculas e adicionar anos ou símbolos. O Leetspeak proporciona uma falsa sensação de segurança.

O Truque da Mudança de Teclado (Keyboard Shift)

Para complicar uma frase memorável, alguns usam o truque da mudança de layout de teclado. Por exemplo, você memoriza uma frase como my-cat. Mas, no momento de digitá-la, você coloca os dedos em um teclado QWERTY físico enquanto configurou seu sistema operacional para AZERTY (francês).

A palavra pensada: my-cat
O resultado digitado: ,y)cqt (A tecla ’m’ torna-se ‘,’; o ‘-’ torna-se ‘)’; o ‘a’ torna-se ‘q’).

Isso é uma boa ideia em OPSEC? Não, este método não é suficiente se for usado sozinho. Assim como o leetspeak, uma troca de layout de teclado é uma substituição fixa: um atacante que desconfia dela aplica o mesmo mapeamento a cada tentativa. Em OPSEC, isso é segurança por obscuridade: atrasa um invasor amador, mas não impedirá um ataque direcionado e bem equipado.

Combinada com uma senha que já é forte (como uma frase-senha longa e aleatória), ela acrescenta pouco. Mesmo que um atacante teste mil pares de layouts, isso acrescenta menos de 10 bits, já que log2(1.000) ≈ 9,97. A força continua vindo da frase-senha por baixo.

Como Construir uma Senha Mestra (~250 bits)

Se as listas de palavras, o leetspeak e os truques de digitação têm seus limites, como construímos uma senha mestra que dure? Nosso gerador já classifica 80 bits como “Forte” e 100 bits como “Muito Forte”. Para uma senha mestra que deve durar décadas, este artigo mira muito mais alto: cerca de 250 bits de entropia. A seção quântica abaixo explica por quê, e o que essa margem não garante.

Existem duas maneiras de conseguir isso, dependendo de suas necessidades:

1. Caracteres Aleatórios (para um gerenciador de senhas)

Uma sequência de caracteres gerada inteiramente ao acaso, sem padrão que uma máquina possa explorar: 8}8,_$-p)M&n,XvUCT0o+.5hDE6P^w6b@U-evS0 39 caracteres sorteados ao acaso entre os 91 do nosso gerador: ≈ 253 bits. Ela foi sorteada para este artigo, então agora é pública. Nunca a use.

2. Uma Frase-senha Aleatória (para uma senha que você memoriza)

Palavras aleatórias são mais fáceis de lembrar do que caracteres aleatórios. Cada palavra sorteada da lista da EFF com 7.776 palavras acrescenta cerca de 12,9 bits, então é o número de palavras que dá a entropia. Doze palavras dão ≈ 155 bits, muito acima do limite “Muito Forte” do nosso gerador. Palavras simples só passam de 250 bits a partir de 20 palavras.

Nosso gerador para em 12 palavras. Para passar de 250 bits com menos palavras, marque “Dígito aleatório após cada palavra” e escolha “Dígito + Símbolo” como separador. Onze palavras dão então ≈ 260 bits: depletion78$sporting14~overlap11>macaw86>paced95,paramedic41}blot41$flagstone07;uncanny92/broadways77#say2 Sorteada ao acaso para este artigo, exatamente com essas configurações. Uma senha publicada é uma senha queimada: nunca use esta, nem nenhum exemplo que você leia. Só conta o que é sorteado ao acaso. Colocar maiúscula em cada palavra não acrescenta nada, e palavras escolhidas por você são muito mais fracas do que palavras aleatórias.

A Ameaça Quântica: O Algoritmo de Grover

Por que apontar para 250 bits quando 128 bits já bloqueiam os supercomputadores de hoje? A resposta está na perspectiva de grandes computadores quânticos.

Na criptografia, o algoritmo de Grover permite que um computador quântico pesquise em um banco de dados não classificado muito mais rápido que um computador clássico. Na prática, Grover reduz efetivamente pela metade o nível de segurança de uma chave simétrica ou de uma senha.

Contra um computador quântico que executa o algoritmo de Grover, uma senha com entropia de 128 bits ofereceria, em teoria, uma resistência equivalente a apenas 64 bits. É uma margem muito mais estreita.

Dobrar a entropia mantém a margem: cerca de 256 bits ainda deixariam cerca de 128 bits contra Grover. É daí que vem a meta de 250 bits deste artigo. É uma precaução que este artigo escolhe, não um número tirado de um padrão.

A margem tem limites. A aceleração de Grover é quadrática, não ilimitada. Cada um de seus passos ainda precisa calcular o hash da senha do site, em um computador quântico grande o bastante para executá-lo. Para comparação, com os 100 bilhões de tentativas por segundo que a página do nosso gerador pressupõe, uma busca média em 100 bits já leva pelo menos 200 bilhões de anos.

A lógica lembra Harvest Now, Decrypt Later (HNDL): um banco de dados roubado de hashes de senhas pode ser guardado hoje e atacado mais tarde, com máquinas melhores. Uma margem maior eleva a barreira contra isso. Não é uma garantia permanente.

Arpokrat Password Generator: Crie a sua

Não deixe a segurança dos seus acessos ao acaso. Nosso gerador gratuito cria senhas e frases-senha aleatórias. Para cada uma, ele mostra a entropia em bits e o tempo médio que uma busca levaria.

Ele apenas gera: não avalia uma senha que você já usa. Para a meta de 250 bits acima, escolha uma senha de 39 caracteres com os quatro conjuntos de caracteres. O gerador a mostra como “≈ 253 bits”.

👉 Arpokrat Password Generator

Ele roda no seu navegador. O que ele gera nunca é enviado nem salvo.

O Último Elo Fraco: Reciclagem e Gestão de Acessos

A entropia matemática não protege contra o erro humano. Uma senha de 250 bits perde o seu valor assim que é vazada, se for reutilizada em vários sites (um ataque chamado Credential Stuffing) ou se não for protegida por um segundo fator de autenticação (2FA).

A regra de ouro da higiene digital é só ter que memorizar uma única senha: a sua senha mestra de 250 bits (uma frase-senha aleatória, como acima). Todos os seus outros acessos (bancos, redes sociais, servidores) devem usar senhas aleatórias exclusivas, geradas especificamente para eles.

Para guardar todas essas senhas que você não consegue memorizar, use um gerenciador de senhas. Escolha um que criptografe o seu cofre no seu dispositivo antes de sincronizá-lo (o que costuma ser chamado de zero-knowledge), idealmente um de código aberto e auditado de forma independente.

A Bomba-Relógio: Colete agora, descriptografe depois e o Imperativo Zero-Knowledge

Tue, 26 May 2026 00:00:00 +0000

A dependência dos governos europeus da infraestrutura em nuvem americana representa mais do que apenas um problema de interceptação imediata. A ameaça mais devastadora para as próximas décadas é a estratégia HNDL: “Harvest Now, Decrypt Later”.

Isso não é uma intrusão frontal, mas um roubo silencioso. Agências de inteligência interceptam e armazenam imensas quantidades de dados criptografados hoje, simplesmente porque o custo de armazenamento se tornou insignificante.

Eles esperam pacientemente pelo momento em que os saltos tecnológicos tornarão obsoletas as chaves criptográficas atuais. Um segredo de Estado protegido em 2026 pode se tornar um livro aberto em quinze anos.

Responsabilidade Retroativa e Risco Temporal

O modelo HNDL introduz um conceito novo: dano legal adiado. Com a coleta maciça de dados para descriptografia futura, a confidencialidade torna-se uma variável dependente do tempo.

O modelo científico HNDL define que a confidencialidade falha inevitavelmente quando a vida útil exigida do segredo excede o horizonte de descriptografia do adversário.

Se um Estado não garante a soberania absoluta de sua infraestrutura de hardware, está praticamente assinando uma renúncia de confidencialidade de longo prazo para seus cidadãos.

A interceptação de hoje é o comprometimento de amanhã. Transformar a dependência da nuvem em uma dívida de segurança nacional é uma aposta impossível de pagar.

A Antítese Arpokrat: Impossibilidade Legal por Código

A indústria responde criando ecossistemas radicais de soberania digital. O modelo Arpokrat opera em uma rede descentralizada, protegida pela rigorosa Lei Federal Suíça de Proteção de Dados (FADP).

A lógica central é o Privacy by Design absoluto. Ao remover a necessidade de um número de telefone, o usuário torna-se uma simples chave criptográfica.

Legalmente, se a arquitetura é fundamentalmente Zero-Knowledge, a empresa enfrenta uma impossibilidade técnica de cumprir mandados estrangeiros.

Trata-se de uma salvaguarda matemática e legal imparável: o que você não possui não pode ser divulgado.

Além da Criptografia: Desvalorizando os Dados Alvo

A verdadeira resposta no aplicativo Arpokrat não é apostar na matemática eterna, mas desvalorizar os próprios dados.

Sem metadados centrais para vincular uma mensagem a um indivíduo físico, o conteúdo criptografado perde seu valor estratégico porque se torna inatribuível.

No entanto, o software sozinho não pode fazer nada se o hardware o trair.

A segurança no século XXI exige a independência da própria máquina. A implantação de um SO soberano sem Google tornou-se um requisito absoluto de sobrevivência para quem lida com segredos de Estado.