Define the result before generating anything
This workflow is for developers, security reviewers, and release writers who need a clear key-material record rather than a vague collection of crypto outputs. Decide first whether the deliverable is a BIP39 mnemonic or an asymmetric key pair. The three tools on this page support related tasks, but they do not establish an automatic mnemonic-to-key-pair derivation chain.
Choose the matching path
Use mnemonic-bip39-generator for a 12-to-24-word BIP39 phrase and its validation signals. Use key-pair-generator for the supported general RSA or ECC pair formats. Use ed25519-x25519-keygen-signature-verifier for modern curve material, signing, or verification. Select Ed25519 for signatures and X25519 for key agreement; do not force one operation onto the other.
Prepare a record template before running a tool. It should have a label, algorithm, encoding, public key, intended use, and review date. It must not have a private key, mnemonic, derived seed, or secret seed text. Treat generated secret material as sensitive: do not upload it, paste it into this article, or leave it in application and audit logs.
Verify the handoff
For a mnemonic, confirm the requested word count and checksum when validation is available. For a key pair, confirm that the selected tool returned the expected public and private components, then retain only the public component. If a signature check is part of the review, use matching Ed25519 inputs and keep X25519 on the key-agreement path.
The final acceptance check is procedural as well as cryptographic: the record contains only public material, the algorithm and encoding are unambiguous, failures were resolved rather than hidden, and a second reviewer can understand the result without seeing a secret. For token-specific concerns, see auth-token-security; for the broader signature and trust context, see key-generation-signature-verification.