RSA Toolkit

What RSA Toolkit helps you do

Generate RSA key pairs, then sign and verify messages or encrypt and decrypt with them. It covers the standard public-key operations in one workspace for testing and learning. Key pairs are PEM, signatures use SHA-256, and encryption uses RSAES-PKCS1-v1_5 rather than OAEP.

Key generation and crypto operations run in your browser. Keys and messages are not sent to Haivix.

How it works

Every operation runs in your browser, and the keys and plaintext stay on the device. The underlying libraries are fetched from a public CDN when the page loads, so the code itself comes from a third party at runtime; that is acceptable for learning and interoperability, not for high-assurance key handling. These are low-level primitives, not a complete protection scheme: CBC, ECB and RC4 provide confidentiality only, with no integrity check, so altered ciphertext may decrypt to something an application still accepts. Modern designs pair encryption with authentication, such as AES-GCM or ChaCha20-Poly1305, and keep keys in a dedicated store rather than a form field.

How to use RSA Toolkit

1. Generate a key pair, or paste an existing public and private key.
2. Choose the operation: sign, verify, encrypt or decrypt.
3. Run it and copy the output.
4. Keep the private key out of shared documents and chat logs.

When to use it

• Test signing and verification in an application.
• Encrypt a short message to a public key.
• Generate a throwaway key pair for a demonstration.
• Check that a public and private key belong together.
• Produce a test signature for a verifier.
• Compare PKCS#1 v1.5 output with an OAEP implementation.

When not to use it

• Do not use it to encrypt files or long messages; RSA is limited to a small payload.
• Do not use a browser-generated key as a production identity.
• Do not treat PKCS#1 v1.5 encryption as the modern default; OAEP is preferred.

Example

A message signed with the private key verifies against the matching public key and fails against a different one. A 2048-bit key can encrypt only about 245 bytes with PKCS#1 v1.5 padding, so a longer message must be split or encrypted with a symmetric key. The generated PEM keys start with the usual RSA public and private key headers.

What you can do with RSA Toolkit

• Generate an RSA key pair in PEM format.
• Sign a message with a private key.
• Verify a Base64 signature with a public key.
• Encrypt a short message with a public key.
• Decrypt Base64 ciphertext with the private key.
• Run the operations locally in the browser.

Example: know what you have before choosing an operation

Identify the input format. A raw key in hex, a passphrase and a PEM key are different things, and using one where another is expected produces garbage rather than an error.

Test with a known vector or a short round trip. Encrypt, decrypt and compare before using the tool on data you cannot afford to lose.

Never paste a production private key or long-lived secret into a web page. Use a throwaway key for experiments and a proper key store for real work.

Check the mode and padding against the system you are interoperating with. The same algorithm with a different mode is a different ciphertext format.

Prefer an authenticated mode for anything new. If the tool only offers CBC or ECB, treat the output as a demonstration rather than a protection mechanism.

Record the output encoding as well as the algorithm. Base64, hex and raw bytes are easy to confuse, and a format mismatch looks like a wrong key.

What to know before you start

• RSA can encrypt only small payloads; large data is normally encrypted with a symmetric key instead.
• Browser-generated keys are fine for testing but should not replace proper key management in production.
• Encryption uses PKCS#1 v1.5, which is legacy; OAEP is the safer padding scheme.
• There is no certificate handling, key attestation or secure storage.

Common mistakes

• Trying to encrypt a large message directly with RSA.
• Mixing up the public and private key fields.
• Assuming the signature format matches another library; this tool emits Base64 over the raw signature.
• Using a key pair generated in a browser for real authentication.

Troubleshooting

If verification fails, confirm the message bytes and the key match exactly.

If encryption fails, the plaintext may exceed the key's payload limit.

If a PEM is rejected, check for missing header or footer lines.

If decryption fails, the ciphertext may have been produced with OAEP rather than PKCS#1 v1.5.

Related standards and documentation

• FIPS 197 defines AES, and NIST SP 800-38A defines its common modes of operation.
• NIST SP 800-38D defines GCM, an authenticated mode suited to new designs.
• FIPS 186-5 covers digital signatures, including RSA and ECDSA.
• RFC 8017 defines RSAES and RSASSA, including PKCS#1 v1.5 and OAEP.
• NIST SP 800-57 describes key management and key lifetime practices.