Attestation · luxiquant-receipt-v2

How a receipt works.

Every LuxiBook run emits a signed receipt. This page is the whole mechanism: what is inside it, how to check it yourself in about ten lines of Python, what it proves, and the one thing it cannot prove without your help.

What is inside the token

A receipt is a JSON file. The interesting part is the receipt field, an lxq2_ token whose body is 101 bytes of base64url.

Bytes	Field	Contents
`0..5`	header	`LXQ` magic (3), scheme version (1), flags (1)
`5..37`	public key	32-byte Ed25519 public key of the install that signed
`37..101`	signature	64-byte Ed25519 signature over the payload text

The signed message is the payload text, not the token. The 37-byte prefix is not covered by the signature. The payload is carried in the clear in the same JSON file, so you can read every signed field before you verify anything.

Check one yourself

This is the whole verification. Copy it, point it at any receipt from the evidence register, and run it.

verify.py

# pip install cryptography
import base64, json
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
from cryptography.exceptions import InvalidSignature

with open("receipt.json") as f:
    data = json.load(f)

s      = data["receipt"][len("lxq2_"):]
raw    = base64.urlsafe_b64decode(s + "=" * ((-len(s)) % 4))
pubkey = Ed25519PublicKey.from_public_bytes(raw[5:37])
try:
    pubkey.verify(raw[37:], data["payload"].encode())
    print("PASS: signature valid")
except InvalidSignature:
    print("FAIL: signature invalid")

We also publish a fuller command-line verifier that handles key pinning, batch globs and non-receipt files: verify_receipt.py on GitHub.

The limit, stated plainly

The key travels inside the receipt. So the check above proves the receipt is internally consistent with itself. It does not prove the receipt came from a LuxiEdge install. Generate your own Ed25519 keypair, sign any payload you like, and that snippet will print PASS. We have tested exactly that.

Key pinning is the defense, and it is why we publish five distinct install keys instead of one.

pinning turns it into an identity check

# unpinned: proves internal consistency only, and says so
$ python3 verify_receipt.py r.json
  WARNING  no key pinned. This proves the receipt is internally
           consistent, NOT that it came from a LuxiEdge install.
  PASS  r.json                                        exit 0

# pinned to a key you already trust: a real provenance check
$ python3 verify_receipt.py --expect-pubkey 141ac983...e65d r.json
  FAIL  signer key 601fde51... is not the pinned key   exit 1

Do not trust the signer_fp field on its own. It is data in a file a forger controls. Derive the fingerprint from the embedded key instead: sha256(pubkey_bytes)[:16]. Our verifier does this, and it is checked against all 20 published receipts.

The five published install keys

Each machine in the v0.2.1 matrix holds its own key, generated on the install and never shared. Pin whichever box you were shown.

Device	Compute	Install fingerprint
NVIDIA H200	`9.0`	`2bfca5597ca16c8f`
NVIDIA H100 80GB	`9.0`	`3ad989ab278280eb`
NVIDIA A100-SXM4-80GB	`8.0`	`b487b0ab3ec0008e`
GeForce RTX 5090	`12.0`	`e79f99f28c81035e`
GeForce RTX 4090	`8.9`	`d80dd94a7bdb02b6`

One more caveat we would rather say than have you find. While key custody is a file on disk, any process running as that user on that machine can mint a receipt with that key. Hardware-backed custody is not built yet. Pinning tells you which install signed; it does not tell you that install was well guarded.

The full evidence register Download the binary