# Tag Info

15

PKCS#1 v1.5 describes a method (formally known as RSAES-PKCS1-v1_5) that turns textbook RSA into a (heuristically) secure encryption scheme for small messages (PKCS#1 v1.5 also describes a signature scheme, which the question and this answer do not consider). For a $k$-byte ($8k-7$ to $8k$-bit) public modulus part of public key $(N,e)$, the message to be ...

12

How does the new attack work at top level? In short They used BEAST-like Man in the Browser attack by using Cache-like attacks to perform a downgrade attack against any TLS connection to a vulnerable server. With this, they showed the feasibility of using Cache-like attacks. More detailed Even over the years, numerous mitigation techniques are ...

10

The Structure of PKCS#1 v1.5 as follows; The message $m$ is padded to x = 0x00 || 0x02 || r || 0x00 || m and the ciphertext calculated as $c=x^e\bmod N$ not by $m^e\bmod N$, where $r$ is a random string. Cube root attack cannot be applied since the padding guarantees that messages are not short. The random $r$ make the encryption probabilistic so that ...

8

You are talking about the PKCS#7 padding. There is a simple reason; assume that when the last block is full and you don't apply the padding before encryption and then send the message. When decrypting, the receiver needs to see a padding pattern to remove the padding. What if the last byte is 01 of the message? is it padding or the message itself? ...

7

Hash functions we use, e.g. Sha-1, Sha-256, Sha-512, usually don’t have a sufficiently large range. But we can construct full domain hash via repeated application of a hash function $h$: $FDH(m) = h(m||0)||h(m||1)||\cdots$, then take the leading n-bit. This way the hash value is deterministic and the size is arbitrary. This is something like MGF1 defined ...

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 ...

6

Your message format is; $$\texttt{padded_message} =\texttt{|0x00|message|random_bytes|}$$ You did not specify what will happen if the message is short. If we assume that it is filled with zero then a short message is; $$\texttt{|0x00|0x00...0x00|short message|random_bytes|}$$ Now there is an active attack. Since the attacker knows the public key $(n,e)$ ...

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 ...

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 $... 4 Why don't you use an eXtendible Output Function (XOF) for that ? For example, SHAKE-128, defined in the SHA-3 standard, allows you to hash a message and obtain as output as many bits as you want. This is flexible so that it can be easily adapted to the size of your RSA modulus. 4 There are at least two attacks that breach confidentiality under chosen plaintext attack, allowing to distinguish and perhaps decipher ciphertext for some messages (with low numerical value, e.g. the all-zero message). If the public key$(N,e)$is such that$m\,e<\log_2(N)/8$(that is$m\le85$for the common$e=3$and$2048$-bit$N$), then for some ... 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 The usual padding for block ciphers ("PKCS#7 padding") is not a sequence of zeroes, but a sequence of P = N - (X % N) bytes each with value P. If the message is a multiple of the block size, then a full block of padding is added (where each byte value is the block size). For example, is the message is 15-byte long and the block size is 16 bytes, than one ... 3 In OpenSSL there is an -nopad option. If you don't want the OpenSSL removing the padding bytes, add the -nopad option. openssl enc -d -nopad -aes-128-ecb -in encrypted.txt -K 0123456789 -v -out decrypted.txt Note that you cannot see as C because the OpenSSL doesn't print in hex. To see in hex you can use xxd command xxd -r decrypted.txt 00000000: ... 3 Exposing the size of the plaintext has no security risks. The size of the plaintext is always considered public data. It's not done because it has limited benefit. With a mode like CBC, you cannot encrypt a fractional block. You must pass a whole number of blocks to the encryption function. So you need padding in some form. The ciphertext is a whole number ... 3 Why is this not a problem? Because for two different encryptions the random integers are drawn independently and uniformly at random over the whole range of the multipicative group\mathbb Z_N^*$(in practice this is usually approximated as$[1,n)$). The RSA assumption now literally states that it's difficult to recover the random value from its textbook ... 3 There is an encryption scheme called RSAES-PKCS1-v1_5, or PKCS#1v1.5 for short. There is a signature scheme called RSASSA-PKCS1-v1_5, or PKCS#1v1.5 for short. These two schemes have different security postures. The signature scheme has no particular weakness as long as the implementation is functionally correct and the use of the private key has no ... 3 When you use textbook RSA, the public key is$(e,N)$and the ciphertext of a message$m$is$c = m^e\bmod N$. The encryption process of textbook RSA involves no randomness; this causes the problem. It is easy to see that when having$m_1=m_2$the ciphertexts of them$m_1^e =m_2^e \bmod N$. Deterministic encryption is not CPA-secure. When using a Padding ... 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 ... 3 The standard criterion for security is indistinguishability under adaptive chosen-ciphertext attack, or IND-CCA2. What this means is that the adversary is given: the public key$(n, e_B)$, and an oracle that answers queries of the form: What is the plaintext for the ciphertext message$c$? The adversary's task is to find any pair of messages with a ... 2 As indicated in the comments, using PBKDF2 instead of e.g. PSS is replacing the padding scheme with another padding scheme. PBKDF2 is used as a key derivation scheme that accepts a password. Although that password needs to be encoded as bytes first, it does mean that you use PBKDF2 differently from how it is intended. If PBKDF2 is used without a salt then ... 2 It is safe to xor parameters into the sponge as long as they are uniquely encoded so that they can't be confused with part of a message. The same goes for padding: if two distinct messages are treated the same way because you skipped padding, you're in trouble; e.g., if you use a length prefix then no padding at the end is necessary but you need to know the ... 2 The attack portrayed is that you use Bleichenbacher's Oracle on some system which does PKCS#1v1.5 (thus can't be TLS 1.3) and then you use the Oracle results to impersonate that same system on TLS 1.3. There isn't any way to address this in TLS 1.3 since it isn't a fault in TLS 1.3. If you have one or more RSA keys for which a valid certificate exists ... 1 What is the difference between PKCS#1 v1.5 and PKCS#7? PKCS#7 makes use of cryptographic primitives defined by PKCS#1 v1.5. PKCS#7 is defined in RFC 2315. The modern PKCS#1 is v2.2 (also RFC 8017), and has a modern description of the schemes in PKCS#1 v1.5, including RSASSA-PKCS1-v1_5. Is verifying a PKCS#1 v1.5 signature the same as verifying ... 1 the raw result is truncated to this saved length. You can easily truncate only if you work with small data sets or if you need to encrypt/decrypt a single file / data set. If you have relatively big data set, let say 1 GB, you would first have to save them in a temporary file. If your OS does not support truncating files, you will have to reread this file ... 1 There are a bunch of issues with prepending the message's length to a ciphertext (or indeed encoding it as the first few bytes of plaintext): Lack of Benefit: Explicitly encoding the length when using CBC mode gives you a benefit in exactly one case: When the entire last block would be padding, because otherwise you will need the length and the padding. ... 1 The problem with CBC mode is the padding. When there is a padding error, the server must response a message back to you so that you can send the message back again or encryption the message from the beginning. The padding oracle attack is solely based on this idea. The attacker changes the byte and looks at the response of the server to execute the attack. ... 1 Yes, the length extension is identical for key sizes that are a multiple of 64 as SHA-1 has an input block size of 512 bits. So you would have to generate the exact same padding for the same message in that case. However, commonly this includes the encoding of the length of the input message of the hash in bits. The output of a number of blocks of SHA-1 ... 1 You don't start by manipulating the last byte of the first block. Rather you manipulate the last byte of the last block. You start at the end and work backwards. The side-channel leak in the padding oracle attack is that the server distinguishes between a bad cipher and bad padding. This is the leak that lets you figure out the message. If you try every ... 1 It is nice that you have tested if from the first hands. The textbook RSA encryption is deterministic in the sense that given a public key$(e,n)$and two plaintext$0 \leq m_1,m_2 < n\$ if $$c_1=\operatorname{Enc}_{k_{pub}}(m_1)$$ $$c_2 = \operatorname{Enc}_{k_{pub}}(m_2)$$ than $$c_1 = c_2 \text{ iff } m_1 =m_2.$$ We already say that textbook RSA ...

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