DON'T/TRUST/VERIFY.

An offline, open-source entropy engine for BIP39 seed phrases — air-gapped on a USB stick, and built so every bit of randomness is something you can inspect, audit, and verify. No blind trust.

See how it works View on GitHub Thesis

PRAVIN RAJ MORGAN · C00313630 SETU CARLOW · SUPV. R. BUTLER

4Security tiers

3Entropy sources

256Bits of entropy

0Network calls

TRUST IS/NOT A/SECURITY MODEL.

01

Hardware wallets ask for blind trust.

Every Ledger, Trezor, or secure-element device hides its entropy generation inside proprietary firmware. Users cannot see it, audit it, or verify that the randomness wasn't weakened at the factory. The 2020 Ledger breach exposed 272,000 customer records — turning a list of crypto holders into a target list for physical attacks.

02

Software wallets ship broken randomness.

In 2023, a single bug in Trust Wallet's entropy generator (CVE-2023-31290) produced predictable seed phrases — and attackers drained real wallets. The vulnerability wasn't exotic maths. It was a developer trusting a deterministic seed where random was required. One line of code. Real losses.

03

The user has no way to check.

On every major wallet — hardware, software, custodial — the user sees the seed phrase, and nothing else. No audit trail. No way to prove the randomness was uncompromised. No way to re-derive it from first principles. Trust, but cannot verify.

ATM was built so the user never has to trust anything they cannot verify.

atm@tails:~/docs $ cat architecture.md section 03 / 09

03 // HOW IT WORKS

Four domains. Every step verifiable.

ATM generates a BIP39 seed phrase through a deliberate pipeline — four domains, each one testable, each one isolated, each one destroying its own inputs before control passes to the next.

DOMAIN 01

Entropy
Generation

ATM collects randomness from three independent sources: the operating system's cryptographic RNG, physical dice rolls entered by the user, and an external file chosen by the user. The three sources are combined through domain-separated SHA-256 and sealed with a 32-character commitment fingerprint.

256-bit · OS + DICE + FILE · SHA-256

DOMAIN 02

Mnemonic
Derivation

The sealed entropy becomes a 24-word BIP39 mnemonic through PBKDF2-HMAC-SHA512. Nothing proprietary here — this is exactly the standard that every compliant wallet implements. What's different is that the input to the derivation was verifiable, which means the output is too.

24 words · BIP39 · PBKDF2

DOMAIN 03

Adaptive
Hardening

A six-question threat model assigns the user one of four security tiers — teal, blue, amber, red — based on who they are and what they're protecting. The tier controls everything downstream: passphrase enforcement, reveal stages, vault access, and recovery mechanism.

4 tiers · TEAL → RED · 6-question model

DOMAIN 04

Adaptive
Recovery

Low tiers produce a single encrypted backup file — one password, one .atm file, portable across any machine that runs ATM. High tiers switch to SLIP39 Shamir secret sharing: the seed is split into five shares, any three of which can reconstruct it.

AES-256-GCM · SLIP39 3-of-5

// pipeline trace · generation session

[00:00.12] entropy.system → 256 bits collected [ok]

[00:00.31] entropy.dice → 50 rolls recorded [ok]

[00:00.44] entropy.external → file fingerprint sealed [ok]

[00:00.52] commitment.lock → 58848A689DED159EA65A6DEF8814C0E5 [sealed]

[00:00.61] bip39.derive → 24-word mnemonic [ok]

[00:00.67] threat_model.tier → TIER_02 (BLUE) [applied]

[00:00.78] recovery.backup → .atm file · Argon2id + keyfile [encrypted]

[00:00.84] seed.fingerprint → 3FA4-91B2-CC18-A4D1 [displayed]

[00:00.89] memory.wipe → seed + entropy destroyed [ok]

A full generation completes in under a second. Every step is logged, fingerprinted, and wiped.

atm@tails:~/docs $ cat tier_policy.md section 03.5 / 09

03.5 // four tiers

Four tiers. Four threat models.

ATM doesn't force every user into the same security model. A six-question threat assessment maps each user to one of four tiers. Every downstream decision — entropy requirement, recovery mechanism, passphrase policy, vault behaviour — adapts to the assigned tier.

TIER 01 · TEAL

Threat level: LOW

Lowest risk profile. Designed for users who want transparency and verifiability over their key generation without requiring defence-in-depth mechanisms.

Entropy256 bits minimum

RecoveryEncrypted .atm file · PBKDF2 + AES-256-GCM

PassphraseOptional

VaultDestroys on scope exit

TIER 02 · BLUE

Threat level: MEDIUM

Moderate threat profile. Introduces a second factor — a keyfile stored separately from the encrypted backup — for defence against a single compromised device.

Entropy256 bits minimum

RecoveryEncrypted .atm file · Argon2id + keyfile + AES-256-GCM

PassphraseOptional

VaultDestroys after first access

TIER 03 · AMBER

Threat level: HIGH

High risk profile. Switches to Shamir secret sharing — no single copy of the seed can reconstruct it. Passphrase is enforced. Entropy requirement increases to reduce the influence of any single source.

Entropy384 bits minimum

RecoverySLIP39 Shamir · 3-of-5 shares

PassphraseRequired · min 16 chars, 4 words

VaultDestroys after first access · max 1

TIER 04 · RED

Threat level: EXTREME

Highest risk profile. Same cryptographic recovery model as Tier 3, but the vault is single-use — the seed is accessed exactly once and destroyed immediately. Entropy requirement is maximised.

Entropy512 bits minimum

RecoverySLIP39 Shamir · 3-of-5 shares

PassphraseRequired · min 16 chars, 4 words

VaultSingle-use · immediate destruction

atm@tails:~/session $ python -m atm.generate section 04 / 09

04 // SEE IT WORK

What a session looks like.

From launch to a seed phrase on paper takes about four minutes of real time. The walkthrough below shows the key moments — threat questionnaire, entropy collection, fingerprint verification, and recovery shares.

atm (threat/model) > Q1/6: Are you concerned about targeted phishing, malware,or compromised devices? [1] Yes ← selected [2] No 1

STEP 01

Threat questionnaire

Six questions assign a tier. Recommendation plus override.

atm (generation/entropy) > Roll your dice (50 rolls): [####> ] 45/50 last roll: 4 system: 256 bits collected file: external_entropy.txt 3

STEP 02

Entropy collection

Three independent sources. Bit accounting shown live.

atm (verify/fingerprint) > Seed Fingerprint: 3FA4-91B2-CC18-A4D1 Record this. Required for verification later without revealing mnemonic confirm

STEP 03

Fingerprint display

Deterministic, re-derivable, user-auditable.

atm (recovery/shamir) > SLIP39 Share 3 of 5: academic acid adequate brave buyer client daisy detect... location: home safe set ID: 3FA4-91 next share

STEP 04

Recovery shares

Split 3-of-5. No single copy can recover the seed.

atm@tails:~/docs $ diff atm ledger trezor trust-wallet section 05 / 09

05 // COMPARISON

What other wallets don't show you.

Most wallets ask for trust. ATM lets you verify. A comparison of trust models across key security dimensions.

Trust Model Comparison	Ledger	Trust Wallet	ATM
Firmware audit	Closed source	Open source	Fully open source
Entropy source	Proprietary TRNG	OS / platform RNG	User + OS + external
Verification at generation	No cryptographic verification	No cryptographic verification	Commitment fingerprint
Verification without revealing mnemonic	Not supported	Not supported	Seed fingerprint + QR
Metadata exposure	High (KYC database)	Medium	Zero (air-gapped)
Recovery model	Standard BIP39 (single-seed recovery)	Standard BIP39 (single-seed recovery)	Adaptive / tier-based
Supply chain trust	Required	Platform dependent	Minimised (user-verifiable)
Execution Environment	Device firmware	Host OS dependent	Ephemeral (Tails, Amnesic)

BUILT ON/A DECADE/OF QUIET FAILURES.

ATM exists because the failures it responds to aren't hypothetical. Operation RUBICON — the joint CIA/BND ownership of Crypto AG from 1970 to 2018 — demonstrated that manufacturers of cryptographic hardware can be captured without their customers ever knowing. The 2020 Ledger data breach exposed 272,000 customer records and turned a hardware wallet's brand database into a target list for physical attacks. CVE-2023-31290 showed that a single bug in a software wallet's entropy generator can produce predictable seed phrases — and drain real wallets. The common thread across all three: the user had no way to check. ATM changes that.

Read the full research context

BUILT BY/ONE STUDENT/IN SIX MONTHS.

Pravin Raj Morgan — final-year BSc (Honours) Cybercrime & IT Security at South East Technological University, Carlow. ATM began as a research question about whether ordinary users could ever truly verify their own private keys. Six months of building, breaking, and rewriting later — this is the answer.

The project was supervised by Richard Butler, with guidance and academic support in cryptographic design from Martin Harrigan.

Graduate availability Open to graduate roles in Cybersecurity — from June 2026.

Email LinkedIn GitHub

AVAILABLE FOR GRADUATE ROLES · 2026 SHOWCASE 2026 · NETWATCH SPONSORED