Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

# Tag Info

16

The input length of OAEP is directly specified in the standard: M message to be encrypted, an octet string of length mLen, where mLen <= k - 2hLen - 2 or simply mLen = k - 2 * hLen - 2 if we want to calculate the maximum message size. Where: k - length in octets of the RSA modulus n hLen - output length in octets of hash function Hash ...

10

Three reasons: Technical: often the integrity and origin of a piece of data becomes immaterial after the data is acted upon; and for long-term use (e.g. document signing), if the security of the signature becomes questionable, there is often the option to stop considering the key valid, and make a new signature with a larger key size, restoring security. ...

10

Do we consider RSA+OAEP secure because the number of possible padded representations of a message is some insanely large number, and thus not feasible to bruteforce with current hardware? No. But a related proposition holds: we would consider RSA+OAEP insecure if the number of possible padded representations of a message was less than some large number, ...

9

RSA in general is often considered to be "discouraged" for new projects. For quite some years, the rallying cry has been "switch to elliptic curves", but nowadays there are calls for going straight for so-called "post-quantum" schemes. RSA benefits from having survived a lot of public scrutiny (arguably, integer factorization is a problem that has been ...

9

One good reason not to use RSAES-OAEP for signature is because as it stands, it can't do signature! RSAES-OAEP performs encryption of a message (of limited length) with optional label into a cryptogram, and decryption thereof. There is no way to turn some RSAES-OAEP black box into a signing machine. OK, we could define an RSA signature scheme with a ...

7

Bouncy Castle Java releases 1.60 and FIPS 1.0.1 (and former) have precisely the issue exploited in Manger's attack: an exception occurs when a ciphertext $c$ is submitted such that $c^d\bmod N$, expressed as a bytetring as wide as $N$, does not start with a 0x00 byte; and then the rest of the decryption process does not occur, leading to markedly faster ...

7

Uses for SHAKE/XOF functions Community wiki answer, please add and edit: key derivation of any type such as turning a 128-256 bit secret key into an ECC or RSA public/private key pair deterministic secure uniform random number generation starting from a small seed this might be used in fuzzing tools, simulations, etc. where you want a lot of random data ...

6

Well, yes, everyone (or, at least, everyone who can use the public key) knows the hash function H and G; so we can assume that an adversary knows them as well. You ask: If YES: How does it help the security, if he just can decode the padding and read the message? Well, he can't decode the padding; the ciphertext has been encrypted using RSA, and he ...

6

To decrypt the ciphertext you definitely need to recover the random token $r$. But $r = Y \oplus H(X)$. Then knowing $r$ the padded message can be recovered as $m0\dots0 = X \oplus G(r)$. The decryptor only need to known the size of the random token $r$ and this is usually part of the standard. Of course the standard has to define the $F$ and $G$ functions ...

5

First off, the maximum size of a message you can use is determined by the desired length of the padding (in my case, I am using RSA-2048 so I wanted a final padded length of 256 bytes) and the hash function you are using. The formula is messageLength = desiredLength - 2 * hashOutputSize - 1 (in my case, I wanted to use SHA-256 so hashOutputSize would be 32 ...

5

You'll have to ask the author of that site why they made that assessment. Although there's no technical reason to prefer RSA-OAEP over the much simpler (to implement and to study) RSA-KEM, RSA-OAEP is more widely standardized and deployed, as RSAES-OAEP in PKCS#1 v2. There are other RSA-based public-key encryption schemes out there, but since that site ...

5

The answer is relatively simple, but I'll expand on the details of the changes from PKCS#1 2.0 to 2.1 in two additional sections below this answer. On the padding with the zero valued byte The I2OSP function - used during decryption - converts an integer to a statically sized, unsigned, big endian octet string or byte array. This function will always ...

5

For any reasonable RSA-based encryption (or signature) scheme, exponent $e = 3$ is a perfectly good choice and provides the best performance for the public-key operation short of qualitatively different Rabin-type schemes. Don't use RSAES-PKCS1-v1_5. RSAES-OAEP of PKCS#1 v2 is reasonable in this sense, though it is unnecessarily complicated. RSA-KEM is even ...

5

You are right that in decryption we need to know the value of $r$, but this can be easily recovered from the ciphertext alone, in fact, $r = Y \oplus H(X)$ and both $X,Y,H$ are known. Then the message can be recovered as $m00..0 = X \oplus G(r)$ Now, you might wonder how to depad from zeros, or equivalenty how can the decryptor distinguish between $X$ and $... 5 Since the input sizes are fixed, length-extension attacks are not relevant, so any of the SHA-2 functions reasonably implements the random oracle model assumed by OAEP or PSS via MGF1—even the default of SHA-1 works with MGF1. Obviously it will cost slightly more to use SHA-224 or SHA-384 than to use SHA-256 or SHA-512 because SHA-224 and SHA-384 are ... 4 If you know the hash functions, yes. If the hash functions are secret, no—but how would you come into a situation where OAEP is being used with a secret hash function? For any hash functions$G$and$H$, OAEP is a fixed permutation involving no secret keys. Specifically, given a message$m$and randomization$r$, OAEP returns$(a, b)where \begin{align} ... 4 Both PKCS#1 v2.1 and RFC 3447 define OAEP in quite a different way. In the graphic used on Wikipedia a lot of things are missing (for instance the label and the exact sizes of the fields). To answer your question: The cryptographic functions G and H both are typically the function mgf1 (mask generating function) with SHA1 as defined by RFC 3447. Pseudocode ... 4 After some thought, I think the answer is in fact NO, even for IND-1-CCA* and even for Shoup's OAEP+. RSA-OAEP/OAEP+ work by taking a messagem$, producing a padding$p(m,r)$and then encrypting this, so$c = f(p(m,r))$where$f$is RSA encryption, and$f(u) = u^e \pmod{N}$is deterministic. In fact, the whole point of OAEP(+) is to inject some entropy ... 4 Yes, RSA encryption without padding as used by RSASVE in NIST SP800-56B is secure. The RSASVE Generate Operation in NIST SP800-56B §7.2.1.2 is given on input an RSA public key$(n,e)$; generates a random secret bitstring$Z$uniformly distributed on range$[2,n-2]$; computes$C=Z^e\bmod n$(as in textbook RSA encryption); outputs the secret$Z$and the ... 4 Is this step necessary? Yes. Assuming you don't want to adopt a RSA-KEM based approach, you need some form of padding to gain full IND-CCA2 security (textbook RSA even lacks the much weaker IND-CPA security!) and OAEP is the preferred such scheme, having a security reduction for IND-CCA2 (that is, it's IND-CCA2 as long as some reasonable assumptions hold). 4 I believe$\mathit{lHash} \mathbin\Vert \mathit{PS} \mathbin\Vert \mathrm{01}$serves the rôle of the zero-padding in$s = (m \mathbin\Vert 0^{k_1}) \oplus G(r)$from the formulation of RSAES-OAEP in the standard reference for its security reduction, on p. 5. Verifying that it matches exactly what you intend is critical for the security reduction to work, ... 4 Direct use of textbook RSA for encryption is very insecure. For example, a guess of the plaintext can be checked: if what's encrypted is a name on the class roll, enciphering all names on the class roll until getting the ciphertext breaks confidentiality. There are several other attacks. That motivates RSA-OAEP. It turns textbook RSA, a hash, and a source ... 3 No, knowledge of$\operatorname{OAEP}(M_1)\oplus\operatorname{OAEP}(M_2)$does not disclose information about plaintexts$M_1$or$M_2$. In particular it does not allow to recover either, even with full knowledge of the other. More generally, it does not help predict any efficiently computable function of$M_1$and$M_2$. The reasons lies in the definition$...

3

We can distinguish between ciphertext of textbook RSA and RSA/OAEP when textbook RSA is misused and insecure; or with knowledge of the private key. With knowledge of the private key, we simply attempt RSA/OAEP decryption. If it succeeds, we bet for RSA/OAEP (and that will hold except for a vanishingly small proportion of possible plaintext); otherwise we ...

3

Let's start with the preliminaries. The basic scheme has encryption defined as follows: $$\mathcal{E}^{G, H}(x) = f(x \oplus G(r) || r \oplus H(x \oplus G(r)))$$ Some definitions: $f: \{0,1\}^k \rightarrow\{0, 1\}^k$ is a trapdoor permutation where $k$ is the security parameter $x$ is the message to encrypt $n = |x|$ is the bit length of the message $k_0 ... 3 The first hash is only used to hash the label. Most of the time the label will simply be empty, which means that a constant value can be used, identified just by the hash algorithm itself. Although the hash values may differ and may have any SHA-x value, they are generally set to SHA-1 - which is the default. Note that SHA-1 is considered secure for MGF-1. ... 3 The padding used for RSA is not the PKCS #5/#7 padding (as you seem to suggest in your own answer), but the Wikipedia entry seems to refer to PKCS #1 v1.5 (RFC2313)) which uses a padding 00 || BT || PS || 00 || D where for RSA encryption we start with a 0x00-byte (to guarantee that the resulting number is below the modulus), then use BT (Block Type) equal ... 3 First, when using padding (PKCS or OAEP), if the chiphertext has errors in transmission we'll we always get an error at the decyption process? Yes, with extremely high probability. This is basically a chosen ciphertext attack and RSA-OAEP is fully immune to them, so the odds that you won't detect this attack (a.k.a. "error") are extremely low (below$2^{...

3

when encrypting a session key which is used to encrypt bulk data using a block cipher for example, is padding with OAEP really needed ? No if the session key is nearly as wide as the RSA modulus, or is padded with random bits up to that size (save for one bit or few high order bits). Absent other issues, we are safe if the actual session key keeps bits from ...

Only top voted, non community-wiki answers of a minimum length are eligible