skip to content

How do you obtain and configure a Cipher for RSA in Java, and what does a transformation string like "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" mean?

level: middleimportance: must knowfreq 60%

answer

  1. transformation = algorithm/mode/padding
  2. ECB token is a no-op for RSA (single block)
  3. OAEP = randomized, IND-CCA2 safe padding
  4. avoid PKCS1Padding (Bleichenbacher), never NoPadding
  5. specify OAEPParameterSpec for MGF1 hash interop

basics

~10 s

Call Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding") to get a Cipher, then cipher.init(...) with a key. The string names the algorithm (RSA), a mode, and the padding scheme used to make encryption safe.

solid answer

~40 s

You get a Cipher with Cipher.getInstance(transformation), where the transformation is "algorithm/mode/padding". For RSA the standard secure choice is "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". The "ECB" token is a historical quirk and means "no chaining" - RSA only ever processes one block, so there is no real block-cipher mode. The important part is the padding: OAEP (Optimal Asymmetric Encryption Padding) randomizes the plaintext before encryption and is the modern, IND-CCA2-safe choice, with SHA-256 as the hash and MGF1 as the mask-generation function. After getInstance you must init the Cipher with a mode constant (ENCRYPT_MODE/DECRYPT_MODE) and a key. Avoid "RSA/ECB/PKCS1Padding" for new code (padding-oracle weaknesses) and never use NoPadding, which is textbook RSA and is insecure and deterministic.

code

java · 11 lines
java
import javax.crypto.Cipher;
import javax.crypto.spec.OAEPParameterSpec;
import javax.crypto.spec.PSource;
import java.security.spec.MGF1ParameterSpec;

Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
// Pin MGF1's hash too, so encrypt/decrypt sides agree across providers:
OAEPParameterSpec oaep = new OAEPParameterSpec(
        "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
cipher.init(Cipher.ENCRYPT_MODE, publicKey, oaep);
byte[] ciphertext = cipher.doFinal(plaintext);

go deeper

for a junior

Knows you call Cipher.getInstance with a transformation string and then init it with a key before encrypting.

for a middle

Can decode the algorithm/mode/padding grammar, knows OAEP is the safe RSA padding, and that the ECB token is a historical no-op for RSA.

for a senior

Explains why NoPadding/PKCS1Padding are unsafe, the IND-CCA2 property OAEP provides, and the MGF1-hash interop gotcha requiring OAEPParameterSpec.

for a principal

Sets organization-wide crypto standards (mandate OAEP-SHA256, ban NoPadding/PKCS1), reasons about provider/FIPS compatibility, and weighs RSA vs ECIES/hybrid for the threat model.

## What problem RSA solves **Symmetric** encryption uses one shared secret key for both encrypt and decrypt - fast, but both parties must already share the secret. **Asymmetric** (public-key) encryption uses a *pair* of keys: a **public key** (publishable to anyone) and a **private key** (kept secret). Anything encrypted with the public key can only be decrypted with the matching private key. **RSA** is the classic asymmetric algorithm, named after Rivest, Shamir, Adleman. ## The Cipher engine In Java, the **JCA/JCE** (Java Cryptography Architecture / Extension) exposes encryption through the `javax.crypto.Cipher` class - an *engine* class. You never construct it; you ask a factory for one: ```java Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); ``` The string argument is the **transformation**. Its grammar is `algorithm/mode/padding` (or just `algorithm`, letting the provider pick defaults - which you should avoid, because defaults vary by provider/version). ## Decoding "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" - **RSA** - the algorithm. - **ECB** - normally "Electronic CodeBook", a *block-cipher mode*. RSA is **not** a block cipher; it encrypts exactly one chunk of data that must be smaller than the modulus. So "ECB" here is a **misleading historical token** that effectively means "no chaining mode" - it does NOT carry the well-known ECB weaknesses of symmetric ciphers because RSA never processes more than one block. - **OAEPWithSHA-256AndMGF1Padding** - the **padding scheme**. **Padding** here means a randomized, structured transformation applied to the plaintext *before* the RSA math. **OAEP** = Optimal Asymmetric Encryption Padding. It mixes in randomness using a **hash** (here SHA-256) and a **mask generation function** (**MGF1**, itself built on a hash). The randomness makes the ciphertext non-deterministic (encrypting the same data twice yields different ciphertexts) and gives the strong security property **IND-CCA2** (indistinguishability under chosen-ciphertext attack). ## Why padding matters so much - **NoPadding** = "textbook RSA": deterministic, malleable, leaks equality of plaintexts, and is insecure for real data. Never use it for encryption. - **PKCS1Padding** (the older PKCS#1 v1.5 scheme) adds randomness but is vulnerable to **padding-oracle / Bleichenbacher** attacks when an attacker can observe decrypt success/failure. Avoid for new code. - **OAEP** (PKCS#1 v2) is the modern recommended choice. Note a subtle JCA gotcha: with `OAEPWith...AndMGF1Padding`, the SHA you name (SHA-256) applies to OAEP, but the MGF1 default hash may differ unless you pass an explicit `OAEPParameterSpec`. For interop, specify it: `new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT)`. ## Lifecycle `getInstance` only creates the object; you must then `init` it (next question) before `doFinal`. A `Cipher` is **stateful and not thread-safe** - use one per operation/thread. ## Possible exceptions `getInstance` throws `NoSuchAlgorithmException` (no provider supports the algorithm) or `NoSuchPaddingException` (algorithm exists but the padding does not).

  • Why is OAEP preferred over PKCS#1 v1.5 padding?
    OAEP adds randomness via a hash + MGF1 and achieves IND-CCA2 security; PKCS#1 v1.5 is vulnerable to Bleichenbacher padding-oracle attacks when decrypt success/failure leaks.
  • What exceptions can Cipher.getInstance throw and what do they mean?
    NoSuchAlgorithmException (no provider implements the algorithm) and NoSuchPaddingException (algorithm exists but the requested padding is unavailable).

saying these in an interview costs you the question

  • Thinking "ECB" in the RSA transformation carries the symmetric-ECB pattern-leak weakness
  • Using RSA/ECB/NoPadding ('it worked in the test') for real encryption
  • Believing getInstance alone is enough to encrypt - forgetting init
  • Assuming the MGF1 hash automatically matches the OAEP SHA-256 across providers

context

resolving links…