An RSA key for Bitbucket is an asymmetric key pair — a public SubjectPublicKeyInfo PEM block for distribution and a private PKCS#8 PEM block for decryption — generated locally as a 2048- or 3072-bit RSA-OAEP modulus with SHA-256 and exponent 65537. The RSA Key Generator creates both blocks in your browser using the platform's Web Cryptography implementation, so no private bytes ever travel to a remote server and two consecutive generations always return different keys even when every setting is identical. Because the underlying algorithm asks the browser to find two large random primes and combine them with the fixed public exponent 65537, randomness is a built-in property of correct operation rather than an optional feature. The public PEM begins with -----BEGIN PUBLIC KEY----- and can be handed to any system that needs to encrypt data for the holder. The private PEM begins with -----BEGIN PRIVATE KEY----- and grants anyone who obtains it the ability to decrypt matching ciphertext, so its handling determines the security of the entire workflow.
What the RSA Key Generator Produces
The page exposes a single, fixed configuration: a modulus of either 2048 or 3072 bits, the SHA-256 hash, and the standard public exponent 65537. There is no option to select 1024-bit keys, custom exponents, raw RSA, or PKCS#1 v1.5 padding, because the tool deliberately restricts itself to the parameters that interoperate cleanly with modern software and that avoid well-known misuse patterns. Generation is asynchronous, and a job identity prevents an older in-flight request from overwriting newer settings.
After generation, the public key is exported as an ASN.1 SubjectPublicKeyInfo (SPKI) DER blob that is then Base64-wrapped at 64 columns and prefixed with the standard PEM header. The private key is exported as an unencrypted PKCS#8 DER blob with the matching header. The underlying browser interface that produces the bytes follows the W3C WebCrypto API. Importing these blocks back into another Web Crypto context, or into a library that supports the same envelopes, must report the same modulus length you selected — that round-trip import is the foundation of the page's correctness check, because secure key generation cannot rely on a fixed golden value to confirm behavior.
Why RSA-OAEP PEM Fits a Bitbucket Workflow
Bitbucket is most often associated with SSH keys for Git operations, but several adjacent Bitbucket-related tasks consume RSA keys in standard PEM form rather than the OpenSSH line format that ssh-keygen produces. Custom integrations that encrypt payloads for a build agent, webhook receivers that decrypt payloads with a stored private key, and self-hosted runners that need to decrypt credentials at startup are all cases where a 2048- or 3072-bit RSA-OAEP PEM pair is the correct artifact. The tool's output is also a clean input for downstream format conversion: a PKCS#8 PEM private key can be transformed into an OpenSSH-format private key with a standard conversion step if a particular Bitbucket workflow does require SSH authentication, although that step is outside the page itself.
For readers whose primary need is a Bitbucket SSH key directly, the PEM versus OpenSSH comparison guide covers the conversion path in more detail. For the encryption-only use cases that the tool actually targets, the RSA-OAEP PEM pair is the correct shape out of the box and needs no further conversion before distribution.
Generate the RSA Key Pair Step by Step
Follow these steps to produce a working RSA-OAEP PEM key pair for a Bitbucket-related task. The procedure assumes you have already confirmed that the receiving system expects RSA-OAEP with SHA-256 and accepts SPKI public plus PKCS#8 private PEM envelopes.
- Open the RSA Key Generator page in a trusted, patched browser on a device you control, with extensions limited to those you trust, because clipboard managers, browser extensions, and host malware sit outside the page's no-upload guarantee.
- Select the modulus size: 2048 bits for broad interoperability and faster generation, or 3072 bits when the application explicitly asks for the larger security margin and can tolerate slower key creation.
- Click the generate control and wait for the page to finish producing the key pair. 3072-bit generation takes noticeably longer than 2048-bit because the browser has to find larger random primes, so do not interrupt the operation.
- Copy the public PEM block to the system, service, or webhook endpoint that needs to encrypt for you. The public key is safe to distribute and may be sent over any channel.
- Copy the private PEM block and import it directly into your protected keystore, secret manager, or encrypted vault. Do not paste it into a chat window, a ticket, source control, analytics, or ordinary notes, because the exported PKCS#8 is not password-protected.
- Clear your clipboard history and close the generator tab once the private key has been moved into protected storage. The private key bytes are no longer needed in the page, and leaving them in the clipboard risks accidental exposure.
- Run an end-to-end encryption test using the exact protocol the receiving application uses: encrypt a known UTF-8 message with the public key through the application, transport the ciphertext, and confirm the private key recovers the original bytes exactly. A PEM that imports successfully is not sufficient on its own, because mismatched RSA-OAEP parameters on the other side will silently fail.
Connecting the Generated Key to Bitbucket
How the generated PEM pair is consumed depends on which Bitbucket-related surface is involved. For a webhook receiver or build agent that encrypts payloads with the public key, paste the BEGIN PUBLIC KEY block into the configuration field exactly as exported and import the BEGIN PRIVATE KEY block into the decryption service's keystore. For an API integration that signs tokens with a separate signing key but verifies identity using RSA encryption, the public PEM travels to the verifier while the private PEM stays on the issuing host.
If the actual goal is to push and pull Git repositories over SSH, an OpenSSH-format key is still required. The cleanest path is to take the PKCS#8 PEM private block produced by the tool, save it to a local file, and run a standard OpenSSH conversion command to produce an OpenSSH private key plus the matching .pub line. That converted key can then be uploaded to Bitbucket's SSH key settings in the usual way. The page itself does not perform this conversion — it stops at the PEM envelopes because those are the formats the underlying Web Crypto implementation can emit and verify.
For a self-hosted Bitbucket Data Center instance that needs a key for an internal service, follow the same import procedure but treat the private key with the same controls as any production credential: encrypted at rest, restricted to the service account, and audited for access. The Atlassian documentation for viewing and updating the Bitbucket Server SSH private key describes the server-side half of this workflow once the key is in place.
Choosing Between 2048 and 3072 Bits
Both supported sizes use the same SHA-256 hash and the same public exponent 65537, so the choice is purely a trade-off between modulus length, generation time, and the security margin that length implies. The table below summarizes the practical differences; the exact figures for your device depend on hardware and browser, so when you need to know precise timing, run the tool once on your own machine rather than estimating.
| Property | 2048-bit RSA-OAEP | 3072-bit RSA-OAEP |
|---|---|---|
| Modulus length | 2048 bits | 3072 bits |
| Generation time in-browser | Notably faster than the larger modulus | Takes longer because the browser must search for larger random primes |
| Operational cost per RSA call | Lower CPU and memory footprint | Higher CPU and memory cost |
| Interoperability | Broadly interoperable | Supported by current libraries, but some legacy stacks still default to 2048 only |
| Recommended when | The receiving system's documentation does not specify a larger modulus | The application explicitly requires 3072 bits or you want the extra margin |
If you are uncertain which size the Bitbucket-related receiver expects, generate a 2048-bit pair first because that is the most broadly interoperable choice. A 3072-bit pair is the correct answer only when the receiving system has been explicitly configured to accept it; otherwise the larger modulus may be rejected as unexpected.
Safe Handling of the Private PEM
The exported PKCS#8 private key is not password-encrypted. Anyone who obtains that PEM block can decrypt every ciphertext produced by the matching public key, so the file must be moved into protected storage on the same device session that generated it and never copied to a less trusted surface. A protected keystore, an encrypted secret manager, or an HSM-backed vault are appropriate destinations. Ordinary notes applications, chat transcripts, ticketing systems, analytics dashboards, browser sync, and source control are not, because those surfaces are routinely harvested and indexed.
Treat any exposure of the private PEM as a key compromise: rotate the key by repeating the generation procedure, distribute the new public PEM to every system that encrypts for you, and revoke or destroy the old private block. The tool does not offer a built-in revocation list, so the rotation step is a manual process coordinated with the consumers of the old public key.
Close the generator tab and clear your clipboard history once the import is complete. The random-by-design property of correct RSA key generation means that two generations will never produce the same private key, which is why every rotation requires running the page again from scratch and why storing the old block after rotation is safe only if the old public key is also retired. Finally, do not use these keys for purposes the tool does not support: the page explicitly does not create X.509 certificates, certificate signing requests, RSA-PSS digital signatures, SSH line-format keys, or JSON Web Keys, and any later conversion must preserve the RSA-OAEP and SHA-256 parameters declared in the PEM while keeping the private key bytes within the same protected boundary.
If you're weighing options, Generate an RSA Key for GitHub Without OpenSSL covers this in detail.