GitHub Key Atlas · public material only

Keys have jobs.

Mention a GitHub user and see which public keys are meant to verify, encrypt, authenticate, or be refused. A handle discovers candidates; a fingerprint and your policy establish trust.

Try @Spaceghost ↓ Inspect generic SSHSIG ↓

Private stays private. This page never asks for a private key. Message plaintext stays in this tab.

mentioned identity@Spaceghostdirectory hint
VERIFYSSH signing keys
ENCRYPTcapable GPG subkeys
REFUSEDexpired or revoked

01 · Resolve capabilities

A mention finds candidates. It does not grant trust.

Lookup is explicit and bounded. SignedData groups current public directory entries by their declared job, then shows the fingerprint you would pin.

GitHub identities

Start with one or more public GitHub handles. No lookup happens until you submit.

Ready to inspect public key capabilities.

Network disclosure

GitHub receives each submitted handle and your network request. The lab sends no message, signature, or private material, stores no result in browser storage, and may stop when GitHub's unauthenticated rate limit is reached.

Your capability map appears here.

Expect signing keys under VERIFY, encryption-capable subkeys under ENCRYPT, authentication-only keys under LOGIN ONLY, and unsafe lifecycle states under REFUSED.

02 · Keep roles separate

Use every public key for the job it declares.

Algorithm compatibility is necessary, but it is not permission to quietly repurpose a key.

VERIFY

Prove a signature

Current, compatible GitHub SSH signing keys can test a signature made by the owner's private key. Public material can verify; it cannot impersonate the signer.

ENCRYPT

Address ciphertext

Only active GPG subkeys that explicitly declare an encryption capability are eligible. The output must name its format and exact recipient fingerprint.

REFUSED

Fail lifecycle checks

Expired, revoked, malformed, or unsupported material remains visible as an explanation, never as an enabled cryptographic action.

03 · Local encryption

Public in. Plaintext stays put.

The action enables only when the selected identity exposes a current, non-revoked encryption key supported by this local lab. It reads the live GitHub directory with no-store semantics before encryption and again immediately before release, accepts X25519/approved ECDH curves or 3072–8192-bit RSA encryption keys, and allows at most 60 seconds from click and each directory check to release. It pins AES-256 with no compression and MDC integrity, then self-opens and revalidates the exact certificate key. Unsupported keys, removal observed by either directory read, suspension, clock rollback, or packet-policy drift are refused.

Message + explicit recipient

The message remains local to this browser tab. Only the public-key lookup reaches GitHub.
Encryption still requires an exact active recipient fingerprint; a handle alone is not enough.

Resolve the recipient, then choose an active encryption key.

Shareable ciphertext

Confidentiality changes bytes.

Encryption is an intentional transformation with a decrypt step. It is separate from SDB1's promise to preserve an authenticated raw payload unchanged.

04 · Generic SSHSIG inspection

Bring a generic SSH signature, not a secret.

The signer creates the signature with their private key elsewhere. This page checks an arbitrary message and caller-selected namespace against compatible public signing keys returned by a fresh GitHub lookup. A result is released only within 60 seconds of the click and completed directory check, without a visibility or continuity change. It does not parse an SDB1 record or enforce the stricter SDB1 SSHSIG profile.

Exact signed inputs

Sign a file locally with ssh-keygen -Y sign -n signed-data.sdb1 message.bin. The namespace is editable domain separation and must match exactly. Using the profile namespace here does not make this generic lab a complete SDB1-profile verifier.

Paste a public signature to begin. Never paste a private key.

Directory is not authority

  1. 01
    Resolve

    Fetch bounded public candidates from an allowed GitHub endpoint.

  2. 02
    Filter

    Reject wrong jobs, unsupported algorithms, expiration, and revocation.

  3. 03
    Verify SSHSIG

    Check the exact namespace, message, signature, and public key. SDB1 framing and claim policy remain unchecked.

  4. 04
    Pin policy

    Use a fingerprint and stable application identity rule before granting authority.

Current association, not historical proof.

A GitHub lookup says which keys the account publishes now. Durable systems need pinned fingerprints, rotation history, and an explicit policy for removed keys.

The rule worth remembering

A handle routes. Crypto proves.

Use public directories for discovery, complete fingerprints for key identity, and application policy for authority.

Apply the SDB1 policy flow →