# Tag Info

17

This is a common mistake, so I'd like to give an in-depth answer. Basically, what you are proposing is to rely on the ONE-WAYNESS of RSA as a ONE-WAY FUNCTION, rather than relying on its CPA or CCA security as an encryption scheme. The advantage of using RSA as a one-way function is that no padding etc is needed. Now, the first important thing to note is ...

9

It is usually assumed that the length of the message is not secret. Even with padding the approximate length is usually leaked, and necessarily any encryption reveals a maximum length (or at least information content) because the ciphertext cannot in general be shorter than the message. NaCl secretbox does not use a block cipher, but a stream cipher ...

6

ANSI x.923 padding and the padding used within PKCS#7 are functionally equivalent. The last byte of the padding stream is the length of the padding stream. The difference is the value of the other bytes, which are all 0x00 in ANSI, and all the identical to the last byte in PKCS#7. f4 93 d6.00 00 00 00 00 00 00 00 00 00 00 00 0d ANSI X.923 f4 93 d6.0d 0d ...

5

A Padding Oracle attack due to my use of CBC Cipher Mode CBC in and of itself does not directly result in a padding oracle. It is when you abuse the padding after decryption to decide whether or not decryption was successful and then communicate (maybe not even directly) the results of that padding check. Based on your comment that The connection ...

4

First, the advice: What are the best-practices to store the message length / strip away padding? Use standard padding, like PKCS#7 padding. It handles finding the length uniquely for you. Use encrypt-then-MAC to prevent padding oracle attacks. (Or better yet, don't use CBC. Use an authenticated encryption mode like GCM, or use CTR+MAC which doesn't ...

4

Spartacus: Maybe i came out with the solution, since the cryptosystem described above is not CCA-secure, an adversary A can intercept (A,B) and compute a new ciphertext $$C = 2B\bmod N = 2^er^e \bmod N$$ Since he's carring out a CCA-attack he has access to a decryption oracle and since: $$C\neq B$$ the oracle output RSA^{-1}(C) = 2^{ed}r^{ed}\bmod N = ...

3

Yes, this is fine. There is a practical disadvantage in space used, if you don't otherwise need to store the size in plaintext. A size field will usually take 32 or 64 bits, whereas typical padding adds one byte on average. Also, if you use encrypt-then-MAC you need to include the length as part of the authenticated data.

3

If you were using $e=3$, then there is a well known attack by Bleichenbacher that enables the trivial generation of a signature that passes verification. This attack was never published, but is described here. Note that this attack appeared in a real vulnerability in Kindle (and some versions of Android). In any case, the attack does not work for $e=65536$. ...

3

It is an important feature to be able to see if encryption/decryption failed. Sure, padding oracles are a problem, but so is a protocol that doesn't perform intrinsic verification of the performed operation. If you have a key agreement protocol then you need some kind of method of validating that the decryption of the symmetric key succeeded. Now you could ...

3

Your problem is not with the signature scheme, something else is wrong. RSA is specified by the RSA cryptography standard, PKCS#1 (mirrored in various RFC's). The PKCS#1 v1.5 padding was introduced in version 1.5 but it persisted in 2.0, 2.1 and 2.2. Those did however introduce a more secure padding scheme called PSS. Unfortunately nobody calls the ...

3

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

2

As far as I can tell, you just have encrypted data in a DB and are worrying that it can be hacked. In short, encryption works so you're good. In more detail, your analysis of a padding oracle attack is correct. As you don't have any services or APIs or network protocols that partake in the encryption, a padding oracle attack can't occur. Understanding ...

2

Why does this prevent the attack? Why doesn't the attacker just infer that the connection failed because of the bad padding? Why else could the connection fail? Well, the connection may fail because the host decrypted a valid pre-master secret, and it wasn't the pre-master secret that we expect. That is, when the attacker injects his encrypted message, ...

2

Bleichenbacher's attack relies on being able to determine whether the padding was correct or not. The patch tries to ensure that the following two (previously distinguishable) cases look identical to an attacker: the padding was correct, but the attacker has no knowledge of the transmitted pre-master secret — hence he can't use the resulting symmetric keys ...

2

The security proof of RSASSA-PSS assumes that the private key is used only for RSASSA-PSS purposes, that hypothesis is violated, thus the security proof does not hold (but as long as RSASSA-PKCS1v1_5 remains usable, you do not have a security proof anyway). Similarly, the wide consensus that RSASSA-PKCS1v1_5 is secure in practice was formulated without ...

2

Yes, we always have to pad the message. The reason is simple: How do we know if the message has a padding or not if we don't always pad? Let's say we pad with adding only $0$ bits. We got the (after padding) message $0101\,1100\,0000\,0000$ and a block size of 2 bytes (16 bits). Well, what was the original message? Was it $0101\,11$? Or was it $0101\,1100$? ...

2

SSL padding always pads, using 1..blocksize bytes (8 bytes for triple DES, 16 for AES). This padding makes it deterministic independently of the value of the plaintext. It's a padding mode similar to ISO 10126 (only the last padding byte is one less). Other padding values - such as the zero padding performed by PHP's mcrypt library - are also ...

2

I know of no standard like that and also doubt it exists. It would have similar disadvantages as random padding at the end, which is no longer in use: subliminal channel, consumption of randomness which may be expensive. Additionally, it would require knowing the message length in advance, which is a practical limitation.

2

That's correct. Here are the padding instructions from RFC1321, the MD5 spec: 3.1 Step 1. Append Padding Bits The message is "padded" (extended) so that its length (in bits) is congruent to 448, modulo 512. That is, the message is extended so that it is just 64 bits shy of being a multiple of 512 bits long. Padding is always performed, even if ...

2

If the last byte in the block is larger than the block size, that would generate a padding error in SSL 3.0. SSL 3.0 padding is up to $BlockSize-1$ bytes of unspecified data, and one byte with the length of the padding (not including the length byte itself). TLS 1.0 and above allow padding longer than the block size, and requires that each byte contains ...

2

You scheme, let's call it pad-MAC-encrypt, would indeed fix any padding oracle attacks against MAC-pad-encrypt. The reason it isn't used is probably that padding oracle attacks weren't known when CBC schemes were initially defined and now that they are known, there doesn't seem to be a convincing use case for CBC. Other modes have advantages over CBC anyway ...

2

Yes, and it's devastatingly effective, too. See OAEP and other RSA/asymmetric-function padding standards. OAEP is what you should use these days so far as I am aware. PKCS#1 has other defined padding schemes also (eg PSS, PKCS1.5), only some of which are effective.

2

MonkeyDuplex in NORX does not have padding per duplex because it does not need thanks to domain separation. As the plaintext is mixed into the ciphertext, it does so at the sponge rate, the same way as Keccak does during normal sponge operations. This makes it more efficient at the given security level. The standard MonkeyDuplex construction does not have ...

1

It is generally fine EXCEPT the fact, that you should not think that one replaces another : it's the BEST practice to use both, but using one of them is better than not using anything at all. They're helping each other in terms of securing, and they are different things.

1

If the intent of the padding is to make a passive attacker learn only a range instead of the exact message length, do not use real_len + rand(max_padlen). It is more efficient to make the length of the padded message a multiple of a given block size instead. If your protocol has enough latitude to allow large variations of the padding length, you can use a ...

1

For a CBC mode cipher, which is what POODLE applies to, you don't encrypt or decrypt individual bytes, but rather blocks, formed by adding padding to the actual data bytes. For encryption in general every byte can be any value 0 to 255, and the SSL spec allows the padding_length byte to be almost any value, but most if not all implementations only use 0 to ...

1

There exist polynomial time attacks against RSA signatures with constant padding. So, this actually does not exploit the missing check for the padding. It uses index calculus The latest paper that I am aware of in this series is http://www.dtc.umn.edu/~odlyzko/doc/index.calculation.rsa.pdf but you might also be interested in this paper: ...

1

In a Feistel network you can use ANY function and it will be invertible. Of course, in order to get security you need the function to fulfill some property. One of the main reasons to use a Feistel network is to get a pseudorandom permutation. For this to work, you need 3 or 4 rounds of Feistel with a pseudorandom function (with tweaks or independent keys at ...

1

The biggest reason is probably that padding is only required for CBC mode encryption. What you are doing here is to mix the cipher mode used for confidentiality with the MAC required for authentication. By doing this you are decoupling the padding from the decryption: CBC-decrypt; verify authentication tag; unpad. This may not be a problem to create as ...

1

Padding oracle attacks are targeting servers, where the padding oracle attack is performed to attack the encrypted connection between client and server. You use encryption only internally, without an external interface, so yes you are right: There is no interface, where an external attacker could perform this attack. However, your entire setup is flawed ...

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