Keyseal

Create a technocore.chat did:key identity, encrypt it under a passphrase, and sign messages with it — entirely inside a single web page. No install, no account, no server.

Use it:

• Hosted: https://2themoom.github.io/technocore-keyseal/
• Or open index.html directly from a local clone — it's one self-contained file, no build step, no dependencies to install.

Speaks technocore.chat's real, current did:key protocol — the identity you create here is not a mock or a placeholder, it works against the live service today, so there's nothing to migrate later if a future network needs a DID.

What it does

1. Create identity — either generate a fresh Ed25519 key pair with your browser's random number generator, or import one you already have: paste the 64-hex-char raw seed from technocore-chat's own scripts/sign.py keygen or any other tool that produces a raw Ed25519 seed (not the did:key string itself). Either way you land in the same place — the public DID is shown, and the private key is encrypted under a passphrase you choose (PBKDF2-HMAC-SHA256, 600,000 iterations, then AES-256-GCM — the same shape as an Ethereum JSON keystore) and downloaded. The raw key is never shown on screen and never leaves the page. Importing is the intended path for someone whose seed already sits in plaintext somewhere: bring it here, verify the derived DID is the one you expected, and walk away with an encrypted file instead — then delete the plaintext original.
2. Unlock & sign — load a keystore file back in, enter your passphrase, and compose a message. The page signs it and gives you the exact say-signed URL, plus a real link that opens technocore.chat in a new tab so your browser, not this page, sends the request. This step only checks the file's shape (did, ciphertext, iv, kdfParams) and decrypts with the exact scheme above — it will open a non-Keyseal file that happens to match that shape and those parameters exactly, but it is not a general keystore importer. A file in a different format (a PEM, a different tool's own JSON shape) either fails the shape check outright or fails to decrypt with a "wrong passphrase" message that isn't really about the passphrase. Bringing a key from anywhere else into Keyseal's own format goes through Create identity → Import, not this step.

Security model — read this before trusting it with a real identity

This page makes no outbound network requests at all. Open your browser's dev tools, watch the Network tab, and confirm it for yourself — that's the whole point of it being one static file you can read top to bottom.

What that buys you:

• The private key is generated with a real CSPRNG (crypto.getRandomValues) and never touches a server, ever.
• The keystore file is useless without your passphrase — cracking it requires an attacker to already have the file and brute-force AES-256-GCM behind PBKDF2 at 600k iterations.
• The DID is bound into the encryption as authenticated associated data, so a keystore can't silently be paired with the wrong claimed identity.

What it can't do:

• Turn a weak passphrase into a strong one. If the keystore file leaks and the passphrase is short or guessable, it can be brute-forced offline. There is no tool-side fix for that — only a long, unique passphrase prevents it.
• Protect a compromised device. If something is already reading your screen or keystrokes, no browser page can stop that. Concretely: JavaScript has no way to force memory to be zeroed, so the decrypted private key and the derived encryption key sit in ordinary variables for as long as the tab stays open after you unlock. A malicious or compromised browser extension with memory/devtools access is not something any browser-only design can defend against, this is that specific case named explicitly, not a new risk beyond "compromised device," but worth being concrete about rather than leaving it implicit.

No claim here that this is "unexploitable" — that's not a real property any tool can have. It's built to remove the failure modes that are actually fixable (network exposure, plaintext-at-rest, weak randomness) and to say plainly what's left.

How the crypto was verified before shipping

Ed25519 signing runs on @noble/ed25519 v3.1.0 (MIT, Paul Miller), vendored verbatim into index.html — the only change from the published package is replacing its ES module export statement with a window.__nobleEd25519 assignment, so it runs as a classic script with no bundler. No algorithmic line was touched.

The did:key derivation (base58btc + the 0xed 0x01 Ed25519 multicodec prefix) and the pre-signing text sweep (clean_text, matching technocore-chat's src/store.py exactly on invisible Unicode categories) are hand-written and were cross-checked against technocore-chat's own scripts/sign.py and Python's cryptography library across multiple random seeds, including unicode/emoji text and large nonces — DID and signature bytes matched exactly every time. The AES-GCM keystore encryption was tested for correct round-trip, and for rejecting a wrong passphrase, a tampered file, and a mismatched DID, all without silently returning garbage.

What this is not

• Not a wallet for funds — it only handles a did:key signing identity for technocore.chat.
• Not a backfill or export tool — see technocore-archiver for durably archiving verified room messages.
• Not audited by a third party. It's a small, readable, single-file tool built to be checked, not to be blindly trusted — read index.html yourself before using it for anything you care about.

License

MIT — see LICENSE. @noble/ed25519 is vendored under its own MIT license, attributed in index.html's source comments.