MV Tools

Real RSA encryption and signature evidence

How to Use RSA Encryption and Signatures with Clear Public and Private Key Boundaries

A practical guide to testing RSA encryption, decryption, signing, and verification without confusing a public key with a private key—or a successful test with production key management.

MV Tools Editorial TeamUpdated 8 min read

Open tool

Choose encryption or signing before choosing a button

RSA encryption protects a short plaintext for the holder of the matching private key: encrypt with the recipient public key and decrypt with that recipient private key. It does not prove who created the message. RSA signing addresses a different question: sign the exact message with a private key, then verify the signature and exact message with the matching public key. A valid signature does not hide the message.

Write down the goal first: confidential short text, a signature interoperability check, or key-pair format testing. Do not use a signing operation as a substitute for encryption, or encryption as a substitute for sender verification.

The ciphertext is a real result from a one-time RSA-2048 key pair; the public key is redacted to keep the focus on the boundary.
The ciphertext is a real result from a one-time RSA-2048 key pair; the public key is redacted to keep the focus on the boundary.

Keep the public and private key boundary intact

The tool generates PEM-encoded public keys in SubjectPublicKeyInfo form and PEM private keys in PKCS#8 form. The public key can be distributed to an intended verifier or sender; the private key must remain controlled by its owner. Never paste a private key into a ticket, chat, code sample, screenshot, browser bookmark, or shared plaintext file.

Key generation, encryption, decryption, signing, and verification are server requests. The tool states that request inputs are not stored or logged, but this is still not a controlled production key-management system. Use generated keys only for experiments unless you have an approved way to generate, protect, rotate, and revoke production keys.

The test-only private key was used only for this request and was never saved in any guide asset.
The test-only private key was used only for this request and was never saved in any guide asset.

Match padding and algorithms exactly

For encryption, the available choices are OAEP SHA-256, OAEP SHA-1, and PKCS#1 v1.5; the tool defaults to OAEP SHA-256. Start with that default when the other system supports it. OAEP SHA-1 or PKCS#1 v1.5 should be selected only when an existing compatible system requires that exact padding. Encryption and decryption must use the same key pair and padding choice.

For signatures, both sides must use the same SHA-256withRSA, SHA-384withRSA, or SHA-512withRSA selection. Signature verification is byte-sensitive: a changed character, line ending, encoding, whitespace change, or different algorithm makes the check fail. Keep a canonical UTF-8 test message and record the selected parameter with the signature.

Signature verification confirms the exact message and selected algorithm; it does not encrypt the message.
Signature verification confirms the exact message and selected algorithm; it does not encrypt the message.

Use RSA encryption only for a short payload

The interface accepts short text and the API validates an encryption text request up to 2,000 characters, but an RSA operation has a much smaller byte limit determined by the key size and padding. A message can therefore pass the form limit and still return an encryption failure. Test a short ASCII or UTF-8 sample first; multi-byte characters also consume more bytes.

RSA is not a large-file encryption format or general document vault. For an application design, use a dedicated data-encryption scheme for the data and use RSA only where its protocol requires it, such as protecting a small key or testing an established integration. This tool is most useful for small compatibility checks rather than bulk data handling.

The ciphertext is a real result from a one-time RSA-2048 key pair; the public key is redacted to keep the focus on the boundary.
The ciphertext is a real result from a one-time RSA-2048 key pair; the public key is redacted to keep the focus on the boundary.

Run a reproducible, non-sensitive test

Generate a 2048-, 3072-, or 4096-bit test key pair, save neither private key nor sensitive text in shared places, and begin with a simple test message. Encrypt with the public key and decrypt with the paired private key using the same padding. For signatures, sign the exact message and verify it immediately with the paired public key and the same signature algorithm.

Record only what another developer needs to reproduce a safe test: the key size, public-key format, padding or signature algorithm, encoding, and a redacted error category. Destroy test key pairs when finished. If an actual production private key or secret was submitted, follow the owning system’s incident and key-rotation process.

Signature verification confirms the exact message and selected algorithm; it does not encrypt the message.
Signature verification confirms the exact message and selected algorithm; it does not encrypt the message.

Frequently asked questions

Can I decrypt a message with a public key?

No. In this encryption workflow, the public key encrypts and the matching private key decrypts. Signature verification with a public key is a separate operation.

Why did encryption fail for text below the form limit?

RSA has a smaller byte limit based on key size and padding. Try a much shorter test message and confirm the selected public key and padding.

Does a valid signature make the message confidential?

No. A signature supports integrity and key-based verification of the message; it does not encrypt or hide the message.