Threat model and safe use

Security overview

Human Authenticator’s comparisons answer one narrow question: do these two app instances currently derive the same value from the key material associated with devices that were paired and confirmed together?

Use the complete pairing process

1. Meet in person and keep control of both unlocked phones.
2. Open the pairing screen on both phones and scan both directions.
3. Compare all four initial words and every digit of the 20-digit number.
4. Confirm only if both complete values match exactly on both phones.

Do not pair from a screenshot, photograph, message, video call, intermediary, or prerecorded demonstration. The QR contains public, unsigned metadata and does not prove that its displayed name or phone number belongs to the person showing it.

Later comparisons

Compare the rotating phrase live on both paired phones. If values differ near a minute boundary, wait for the next phrase. If disagreement persists, do not rely on the connection; remove it on both phones and pair again in person.

Key handling

Native identity keys are generated from cryptographic randomness. Private keys are stored through operating-system secure storage on iOS and Android. Pairwise keys and displayed comparison values are derived when needed rather than persistently stored. Unsafe peer keys and changed local identities are rejected by the current implementation.

Secure storage protects data at rest, not a compromised runtime. Rooted, jailbroken, debugged, infected, stolen and unlocked, or remotely controlled devices are outside the protection boundary.

Protocol status

The app uses Curve25519 key agreement and TweetNaCl-based, domain-separated constructions. The initial comparison is bound to both fresh pairing-session IDs. The custom application protocol has automated tests and fixed vectors, but it has not received an independent cryptographic audit, formal verification, or third-party penetration test.

High-stakes decisions

Do not use Human Authenticator as the sole control for emergency, financial, medical, legal, life-safety, account-recovery, or other high-assurance decisions. Follow the established verification and escalation procedures of the relevant institution or service.

Report a vulnerability

Email zacharysean8@gmail.com with the affected version, platform, impact, and minimal safe reproduction steps. Use generated test identities and redact logs. Do not send real private keys, complete pairing payloads, or personal data through ordinary email. Please do not publish an undisclosed vulnerability before there has been a reasonable opportunity to investigate and fix it.