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

6

Without a well-designed padding system it may be possible to craft a ciphertext that the decryptor may or may not be able to decrypt properly. Whether the decryptor is able to do so will depend on the private key. The concern is that an attacker may be able to craft a string of ciphertexts, listen in to whether they decrypt properly, and finally deduce the ...

5

In general, use a cryptographic MAC to protect your ciphertext, and verify it first. Emit those errors. Then padding errors should not occur at all. The "in general" seems to have been used to show that commonly is performed or should be performed. I don't think it had anything to do with the security of the scheme itself. PKCS#7 compatible padding can ...

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

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 = 2r\...

4

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.

4

The PKCS 5/7 encoder would not do anything since it has all 16 bytes (1 block size required by AES cipher). That's where you're wrong. Padding should be always applied. If the user is encrypting a plaintext that is already a multiple of the block size, then the PKCS#5/#7 padding schemes will add an additional full block of padding, so that there is no ...

4

I am a cryptographic researcher at Security Innovation, which acquired NTRU. Apart from the aforementioned attack, there are two significant attacks, namely a chosen plaintext attack (CPA) and a chosen ciphertext attack (CCA), when a proper padding scheme is not used. Recall that in an IND-CPA game, the challenger is given two plaintexts, suppose they ...

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

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 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 ... 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 ... 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 In$\text{SHA-512}$the size of the blocks is 1024 bit. The last block must contain: the rest of data in message (mod 1024). some filling (padding) the last 128 bits as length If the message is 1919 bit length: Calculate the size of the data in the last block:$1919 \mod 1024 = 895$Add the size of length field(128 bit) to the last block size(895 bit)... 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 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 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 ... 2 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 ... 2 With block ciphers, I understand that the plaintext is first broken down into the right-sized blocks, padded, and then encrypted into the same number of cipher blocks. Actually, it's a bit more complex than that. There are some block cipher modes (for example, CTR, CFB) that don't require any padding. On the other hand, even if the encryption mode doesn'... 2 In general password hashing (algorithms such as bcrypt, PBKDF2) should contain a specific work factor. It might well be that repeating the hash multiple times will already obfuscate the hash time enough to make the padding redundant. If you consider password hashing a requirement then reducing the number of rounds on the underlying compression function (e.g.... 2 As you are asking about the "best" way to pad, the answer is OAEP for Encryption and PSS for signatures. They are well understood, widely used, and considered secure. They also give you some neat additional properties that your system does not achieve, like preventing partial decryptions and making the message "look random" in the case of OAEP. If you are ... 1 With block ciphers, I understand that the plaintext is first broken down into the right-sized blocks, padded, and then encrypted into the same number of cipher blocks. Basically, you are right. I just mention two things in addition to @poncho's answer: (1) just as @poncho said that, block ciphers can run in different modes of operation. The message must ... 1 RIPEMD-160 uses precisely the same padding and endianess convention as MD5. Everything is little-endian, with the exception of the order of bits in bytes, which is kept big-endian. If the message is$n$-bit, it is appended a single bit at 1 and$511-((n+64)\bmod512)$bit(s) at 0 , then the representation of$n\$ on 64 bits. The resulting padded message is an ...

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

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

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