GPU VOLEitH: FAEST e PERK em CUDA

Implementação CUDA de assinaturas digitais pós-quânticas baseadas em VOLE-in-the-Head — os esquemas FAEST e PERK — com foco em vazão de assinatura em lote. Em uma NVIDIA H100, a implementação assina e verifica em lote até ~34 mil assinaturas/s (FAEST-128f, em lotes de 16.384).

Este repositório é também o artefato do artigo "GPU Acceleration of VOLEitH-Based Post-Quantum Signatures: A Reusable Fragment-Graph Framework" (SBSeg 2026). Os scripts reexecutam a matriz completa de benchmarks com verificação criptográfica e comparam cada medição H100 com os valores publicados segundo a tolerância registrada em benchmarks/. A reconstrução da comparação CPU usa a implementação otimizada oficial do time FAEST (v2 — o repositório hoje publicado como faest-arch-opt, commit fixado 09b2ffb) e o benchmark com 16 processos incluído em cpu_baseline/. Ela cobre as seis linhas FAEST; a coluna CPU de PERK não está incluída.

Estrutura do readme.md

Este README segue o modelo do CTA: Selos Considerados, Informações básicas, Dependências, Preocupações com segurança, Instalação, Teste mínimo, Experimentos (uma subseção por reivindicação do artigo) e LICENSE.

Organização do repositório:

• src/: projeto CMake (código CUDA de FAEST em src/protocols/faest/, PERK em src/protocols/perk/, primitivas comuns AES/Keccak em src/include/unified_gpu/, testes KAT em src/tests/kat/)
• benchmarks/: valores H100 do artigo (h100_reported_baselines.tsv), mapeamento alegação→comando (claim_command_map.tsv) e política de tolerância (tolerance_policy.tsv)
• cpu_baseline/: benchmark normalizado com 16 processos para a comparação com CPU
• build.sh: configuração, compilação e testes
• scripts/run_artifact_local.sh: execução local
• scripts/run_artifact_modal.py: execução remota via Modal

Selos Considerados

Os selos considerados são: Disponíveis (SeloD), Funcionais (SeloF), Sustentáveis (SeloS) e Reprodutíveis (SeloR).

A validação funcional completa requer Linux x86_64, CUDA Toolkit e uma GPU NVIDIA compatível (sm_86+). A reprodução dos resultados de desempenho (SeloR) usa uma H100 via Modal — a conta gratuita inclui créditos iniciais (US$ 30 em Agosto de 2026) que cobrem com folga a reprodução completa; confirme as condições atuais antes de executar.

Informações básicas

Ambiente dos resultados do artigo:

• GPU: NVIDIA H100 80GB (HBM3), CUDA 12.x, via Modal
• Ambiente local testado: Ubuntu 24.04 x86_64, g++ 13, CMake ≥ 3.28, Ninja

Requisitos locais: Linux x86_64 e pelo menos 10 GiB livres. Para a validação funcional completa: GPU NVIDIA compatível, driver NVIDIA e CUDA Toolkit 12.x (o teste mínimo sem GPU dispensa os três).

Dependências

sudo apt-get install -y git cmake ninja-build gcc g++ python3 python3-venv

Para compilar e validar código CUDA em uma GPU local, também é necessário o CUDA Toolkit 12.x (https://developer.nvidia.com/cuda-downloads). Para a reprodução H100 via Modal, o CUDA Toolkit local é dispensável quando Docker está disponível: o prebuild usa a imagem reproduzível de Dockerfile.cuda-build (com o toolkit fixado) e recorre ao nvcc local apenas na ausência de Docker.

O teste local não acessa serviços externos depois do checkout. A reprodução H100 requer rede e uma conta Modal com o CLI autenticado em um ambiente virtual na raiz do repositório, ativado durante a reprodução:

python3 -m venv .venv
source .venv/bin/activate
pip install modal
modal setup

A reconstrução CPU também requer Meson (pip install meson ninja) e clona faest-arch-opt no commit fixado.

Preocupações com segurança

O teste local não abre portas nem usa credenciais. A reprodução remota usa as credenciais Modal do próprio usuário e envia somente os binários e metadados necessários ao job H100.

Este é código de pesquisa orientado a desempenho: antes de qualquer consideração de uso real seriam necessárias, no mínimo, revisão de segurança cuidadosa, auditoria da geração de aleatoriedade das chaves e isolamento estrito de hardware.

Instalação

git clone https://github.com/shyba/gpu-vole.git
cd gpu-vole
./build.sh

O script configura com CMake/Ninja, compila e executa os testes. Para um diretório de build alternativo: BUILD_DIR=/tmp/gpu-vole-build ./build.sh.

Por padrão a compilação usa um único processo, o que funciona em qualquer quantidade de RAM. Para acelerar, aumente JOBS conforme a memória disponível — cada processo de compilação CUDA pode usar alguns GiB; por exemplo, JOBS=6 ./build.sh em uma máquina com 32 GiB (vale também para scripts/run_artifact_local.sh).

Teste mínimo

Em uma máquina com CUDA Toolkit e GPU NVIDIA compatível, o comando abaixo compila a implementação CUDA, executa a suíte criptográfica — incluindo KATs e assinatura/verificação — e valida a instalação produzida:

CLEAN=1 scripts/run_artifact_local.sh

Saída esperada: 100% tests passed, 0 tests failed e Artifact check passed. Esta é a validação funcional do artefato CUDA e requer uma GPU compatível.

A mesma validação pode ser executada remotamente, sem GPU local:

python3 scripts/run_artifact_modal.py check

Teste mínimo sem GPU

Em uma máquina sem CUDA Toolkit (sem nvcc no PATH), os mesmos comandos compilam apenas a parte de host e executam os testes de API, despacho e empacotamento:

CLEAN=1 scripts/run_artifact_local.sh

Saída esperada: 100% tests passed, 0 tests failed out of 9 e Artifact check passed. (menos de um minuto, ~12 MB). Este caminho valida a instalação e os contratos de host, mas não compila nem executa nenhum kernel CUDA — a validação funcional completa continua exigindo uma GPU (local ou via check remoto acima).

Ainda sem GPU, é possível exercitar criptografia real em CPU executando a reconstrução do baseline (Reivindicação #3, cpu_baseline/run.sh): ela compila a implementação FAEST de referência e assina/verifica as seis variantes — note que isso cria o baseline de comparação, não exercita o código CUDA deste repositório.

Validação KAT (correção bit-exata)

Os testes em src/tests/kat/ verificam assinaturas bit-exatas para as seis variantes FAEST do artigo (128f/s, 192f/s, 256f/s) e para os IDs PERK 1, 3 e 5 (AES fast), além da aceitação dos vetores pela verificação. A origem conhecida, as limitações de proveniência e os checksums das fixtures estão em src/tests/kat/vectors/README.md. Fixtures ausentes ou malformadas causam falha explícita.

Experimentos

Os resultados do artigo, os comandos que os reproduzem e as tolerâncias de comparação estão registrados em benchmarks/ (h100_reported_baselines.tsv, claim_command_map.tsv, tolerance_policy.tsv). As duas reivindicações principais do artigo (tabelas FAEST e PERK na H100) são reproduzidas pelo mesmo comando; a reconstrução da coluna CPU é separada.

Reivindicação #1: matriz FAEST na H100 (sign e verify, 6 variantes)

Reivindicação #2: matriz PERK na H100 (sign, IDs 1/3/5 fast AES/AES)

python3 scripts/run_artifact_modal.py publication

O wrapper compila localmente para sm_90 — de preferência na imagem Docker reproduzível de Dockerfile.cuda-build, que dispensa CUDA Toolkit local, ou com o nvcc local quando Docker não está disponível. Outras arquiteturas podem ser selecionadas com GPU_VOLE_CUDA_ARCHITECTURES. Ele executa os testes CUDA quando há GPU local, envia os binários para uma reserva Modal H100!, valida-os remotamente e baixa os logs para um diretório timestampado sob results/. Hashes SHA-256 são conferidos entre build e H100.

Custo e tempo: o prebuild local leva ~10 min; a execução H100 usa poucos minutos de GPU paga. Requer ~10 GiB de disco e ~40 GiB de RAM locais (pico de um único ptxas; GPU_VOLE_BUILD_JOBS compila em paralelo e multiplica esse pico). Timeouts são controlados por GPU_VOLE_MODAL_TIMEOUT (padrão 3300 s) e GPU_VOLE_CASE_TIMEOUT (padrão 180 s).

Cada execução requer um diretório de resultados vazio; para repetir, defina GPU_VOLE_MODAL_RESULTS=results/h100-<identificador>.

Resultado esperado: ao final, o mesmo comando compara automaticamente as medições com os valores do artigo usando benchmarks/tolerance_policy.tsv e reporta cada linha FAEST e PERK dentro da tolerância (ou mais rápida). O diretório de resultados é único por execução e aparece na saída.

Para PERK, esse fluxo usa diretamente as tuplas de publicação registradas em benchmarks/perk_publication_tuples.tsv. Cada tupla passa por validação integral das assinaturas, por um gate E2E byte a byte contra a referência PERK v2.2.0 independente e, para o ID 5, por equivalência entre os caminhos fused e materialized antes da medição.

O código e as tuplas foram corrigidos e retunados após a medição histórica. A comparação automática verifica a reivindicação de vazão da tabela na H100; ela não representa uma repetição do binário, da tupla ou do ambiente de driver históricos. O manifesto registra o ambiente e os controles efetivamente usados.

Reivindicação #3: baseline de CPU do artigo (coluna CPU de FAEST)

cpu_baseline/run.sh

Clona a implementação otimizada oficial (faest-arch-opt, commit fixado 09b2ffb, FAEST v2.0.2), adiciona o benchmark normalizado com 16 processos usado no artigo (cpu_baseline/bench_normalized_rss.cpp), compila com Meson e mede sign/verify das seis variantes via API crypto_sign (setup fora da região cronometrada, 2 s por caso). Os números absolutos dependem da CPU; os do artigo foram medidos em um Intel i7-11800H (8C/16T). Este comando não reproduz a coluna CPU de PERK.

Limites conhecidos

• O teste mínimo sem GPU não compila nem exercita código CUDA; a validação funcional completa requer uma GPU NVIDIA compatível (local ou via python3 scripts/run_artifact_modal.py check).
• Resultados H100 só são comparáveis aos do artigo quando GPU, lote, aquecimento e iterações seguem o manifesto de execução (gravado automaticamente em run_manifest.txt).

LICENSE

GNU Affero General Public License v3.0 (LICENSE). Arquivos Keccak derivados carregam avisos SPDX-License-Identifier: MIT (copyright Tatsuki Ono), que devem ser preservados.