explaingit

maceip/eat-pass

Analysis updated 2026-05-18

0RustAudience · developerComplexity · 5/5Setup · hard

TLDR

A post-quantum security system that issues anonymous, unlinkable access tokens gated on genuine hardware attestation, so servers trust the software without knowing who sent the request.

Mindmap

mindmap
  root((repo))
    What it does
      Verifies hardware attestation
      Blind signs anonymous tokens
      Prevents double spending
    Tech stack
      Rust
      FAEST signatures
      PoMFRIT blind signing
      Redis
    Use cases
      Anonymous authenticated APIs
      Post quantum token systems
      Attestation gated access
    Audience
      Security engineers
      Infrastructure developers

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Gate an API so only requests from a genuinely attested, trusted software build are accepted.

USE CASE 2

Issue anonymous access tokens that a server can verify without linking them back to a specific user.

USE CASE 3

Build a post-quantum-safe authentication layer that survives future quantum computer attacks.

What is it built with?

RustFAESTPoMFRITRedis

How does it compare?

maceip/eat-pass0xr10t/pulsefi404-agent/codes-miner
Stars000
LanguageRustRustRust
Setup difficultyhardhardmoderate
Complexity5/54/53/5
Audiencedeveloperdeveloperdeveloper

Figures from each repo's GitHub metadata at analysis time.

How do you get it running?

Difficulty · hard Time to first run · 1day+

Real use requires genuine hardware attestation (e.g. a confidential VM), native builds are Linux x86_64 only.

In plain English

This project is a security system for proving that a request comes from a trusted, verified piece of software, without ever revealing which specific device or user sent it. It combines two advanced cryptographic techniques, both designed to stay secure even against future quantum computers, which could otherwise break many of today's standard encryption methods. The first technique checks hardware evidence, a cryptographic proof generated by the device itself confirming it is running genuine, unmodified software in a secure environment. Only after that proof passes a policy check does the system issue a short-lived authorization. The second technique then uses that authorization to blindly sign an anonymous access token, meaning the part of the system issuing the token never actually sees the finished token a client later uses. This separation is what makes the tokens unlinkable: a server can trust that a request came from an approved, attested piece of software, while having no way to tell which particular client sent it. In practical terms, think of it as a bouncer who checks that you are wearing the right kind of wristband, without ever learning your name. A server using this system only needs the issuer's public cryptographic key to check tokens, with no callbacks, no shared secrets, and no per-request re-verification needed. The project ships as a single program that can act as four different roles: the attester that checks hardware proof, the issuer that blind-signs tokens, a central authority that prevents a token from being spent twice, and an example origin server that accepts tokens. There is deliberately no insecure or development mode in the shipped software, since real hardware attestation is always required, though a hidden test-only mode exists purely for automated testing. This is deep infrastructure-level security software, written in Rust, aimed at engineers building systems that need strong anonymous authentication, not something a typical developer would use casually. It requires a genuine hardware attestation environment such as a confidential virtual machine to run for real, and currently builds natively only on Linux.

Copy-paste prompts

Prompt 1
Explain how FAEST attestation and PoMFRIT blind signing work together in this eat-pass project.
Prompt 2
Help me run the issuer, attester, redeemer, and origin roles of eat-pass locally for testing.
Prompt 3
Walk me through why this system's tokens are unlinkable even though issuance requires hardware proof.
Prompt 4
Show me how to use the dev-sim test feature in eat-pass without real attestation hardware.

Frequently asked questions

What is eat-pass?

A post-quantum security system that issues anonymous, unlinkable access tokens gated on genuine hardware attestation, so servers trust the software without knowing who sent the request.

What language is eat-pass written in?

Mainly Rust. The stack also includes Rust, FAEST, PoMFRIT.

How hard is eat-pass to set up?

Setup difficulty is rated hard, with roughly 1day+ to a first successful run.

Who is eat-pass for?

Mainly developer.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.