# Tag Info

14

There is only one main difference between PKCS#5 and PKCS#7 padding is the block size. PKCS#5 padding is only defined for 8-byte block sizes. PKCS#7 padding would work for any block size from 2 to 255 bytes. This is the definition of PKCS#5 padding (6.2): The padding string PS shall consist of 8 - (||M|| mod 8) octets all having value 8 - (||M|| mod ...

11

Padding is always added, even if the plaintext is a product of the block size. This way the algorithm look for the last byte(s) and can safely interpret it as padding data. In case of alignment to the block size, a full block is added just for padding purposes. So if your example shows 8 bytes of data and you are using a 64-bit block cipher, a block of ...

6

In their 2012 paper "The Security of Ciphertext Stealing", Phillip Rogaway, Mark Wooding and Haibin Zhang prove that all the NIST-approved ciphertext stealing modes provide the same level of security as ordinary CBC mode, i.e. ciphertext indistinguishability under a chosen-plaintext attack. To quote their abstract: "Abstract. We prove the security of ...

5

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

4

As you note, PKCS7 padding isn't designed to do exactly what you want; it's really designed to allow you to pad up to the next multiple of the block size, that is, to the next multiple of 8 or 16. That it does rather well; however, it's not designed to do what you want with it. I would note that for block ciphers, as long as you also include a good Message ...

4

The documentation says: All the block ciphers normally use PKCS#5 padding also known as standard block padding which is both informative, and slightly misleading. OpenSSL supports, by default, one stream cipher (RC4) and a variety of block ciphers (Blowfish, 3DES, AES...). The enc command (from the command-line tool) encrypts an input file into an ...

3

What are the properties of random padding (and I realize there are different ways to do it but I'm looking for an illustrative example) that allow it to be reliably removed from the message? You can do random padding with AES, but you'd have to reserve say the very last byte to tell how many bytes of padding were added. For example, for a 4 byte ...

3

As poncho said in his comment, you added padding before decryption as well, which is not correct. AES encryption and decryption are both permutations, so if you decrypt data with a key, it will "look" random (at least, if AES is secure). Instead of adding padding, you need to remove the padding from the already decrypted text: from Crypto.Cipher import AES ...

3

Sadly, there's no uniform answer to this. The answer will depend upon your specific application domain. In some application domains, revealing the exact length of the plaintext is not a problem. In other application domains, it is a very serious problem. There's no one-size-fits-all answer. That's probably why you don't find much discussion of this. ...

3

The size of the padding could be made public, if you don't mind leaking some additional information about the plaintext size. Using a hash as padding bytes however does not make sense; you can not use the hash as authentication tag or to check the integrity, so the hash calculation becomes spurious. It may even leak data through a side channel. In the best ...

3

For AES CBC i would suggest you stick to the standards. The PKCS7 padding scheme is pretty easy to implement and has been tested extensively now that its been out in the public for a while. I had implemented PKCS7 padding for my AES CBC cipher a few weeks ago and you can see the code here if it helps. Note that hashing by itself does not provide you with ...

3

SHA-1, SHA-224 and SHA-256 append the bit “1” to the end of the message, followed by k zero bits, where k is the smallest, non-negative solution to the equation l+1+k ≡ 448 mod 512, where l - message length. In second step they use 32-bit words. SHA-384, SHA-512, SHA-512/224 and SHA-512/256 use different equation: l+1+k ≡ 896 mod 1024 and in 2. step ...

3

In this scenario, you don't need to do any padding (except for the first encryption). If what you're encrypting with RSA is a random number between 0 and the modulus size, then you don't need any padding. Padding is there to prevent the attacker from using the multiplicative properties of RSA to derive one plaintext from a bunch of others; this attack ...

2

Bit padding, PKCS#5 padding and PKCS#7 padding are always applied, and they are always applied to the end of the plaintext. The last block of ciphertext will always contain the padding. The padding is always 1 to [blocksize] bytes, which in case of AES is 1 to 16 bytes. For PKCS#5 padding and PKCS#7 padding - which are basically identical - the value of the ...

2

Obviously, PMAC needs a padding because you want to be able to compute MACs of messages which are not multiple of the block length. The padding is defined in the PMAC paper http://www.cs.ucdavis.edu/~rogaway/ocb/pmac.pdf, it simply complete the last block adding a single '1' bit and as many '0' bits as needed. Note that messages whose length are multiples ...

2

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext. CBC padding in general does not add any security ...

2

The security of these schemes is all comparable, as far as I am aware. In all cases, you need to use authentication (e.g., Encrypt-then-MAC). Padding attacks are just one way that security can fail if you omit the authentication, but all of these schemes will have serious security problems if you omit the authentication. So, don't forget the ...

2

PKCS5 padding is a narrowly defined subset of PKCS7 as per its specification. PKCS7 padding is identical to PKCS5 when applied to an 8-byte block only. The PKCS5 specification is actually defined only for DES, not 64-bit block ciphers in general. However, PKCS5 by specification MUST created an invalid padding string when applied to a block size that is ...

2

Read about the CRIME and BREACH attacks. They are the classic example where compression before encryption can leak information about the input. The length of the compressed data leaks information about the contents of the data itself. See also http://security.stackexchange.com/q/19911/971 and http://security.stackexchange.com/q/20406/971 and ...

2

Since this picture is taken from wikipedia, I suggest reading the text beside that picture: G and H are typically some cryptographic hash functions fixed by the protocol. I think you're asking how OAEP and RSA actually are combined, and it goes like this: Use OAEP (choose $r$, follow the instructions and you get $X$ and $Y$) Concatenate $X$ and $Y$, ...

2

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

2

In the blind RSA signature scheme the blinding of a message $m$ (to be blindly signed) is multiplicative with value $r^e$, where you ensure that $r$ is invertible modulo $N$. So if the sender receives the signed blinded message back from the signer, he can unblind by multiplying with $r^{-1}$, yielding $s\equiv m^d \pmod N$ which is a valid (textbook) RSA ...

2

Considering the padding as an addition, padded message passed to sign is $m\cdot 2^{16}+0101$, $0101$ in hexadecimal, assuming padding is done on the lower bytes (for higher bytes the logic is just the same). Being $e$ the private exponent, and $m^2$ computed in the size of $m$, $(m\cdot 2^{16}+0101)^e \pmod m$ is very different from $(m^2\cdot ... 2 The first byte is 0x00, because some standards allow RSA key sizes$8b+1, b \in \Bbb Z_+$. Such key would have 0x01 at the first bit, but it is possible for almost all other bits to be zero. Thus, 0x00 as the first byte allows interoperability with all possible RSA key sizes. NIST's recommendations and few other standards actually recommend only few ... 2 What the specification is saying is that prior to processing, the message is padded to a full block length, with the empty message padded to a single block. The spec on page 4 describes the input into the algorithm as: Define$||a||_n = max\{1, \lceil|a|/n\rceil \}$, where the empty string counts as one block Let$m = ||M||_n$Partition$M$into$M[1] ... ...

2

ECB, CBC and such cipher modes are something that relate to symmetric cryptography. In context of RSA, it is important to study from documentation of the product what they mean as they do not ordinarily apply. Based on the articles you provide, this statement is correct: The mode, ECB in this case, is ignored for RSA.Use PKCSPadding. The max amount of ...

2

Though Bob may potentially delay his response by one year or more, the attacker may probably assume that, in practice, Bob will respond rather promptly. Thus, an active attacker can infer from Bob's response, or lack thereof, whether decryption occurred or not. This is a setup where Bleichenbacher's attack seems to apply. However, one must take the fine ...

2

In HMAC, the key $K$ [after it has been replaced by $H(K)$ if $K$ was wider than the hash's internal block size] is padded with zeros to the hash's internal block size. The question asks why this padding. In a nutshell: the security argument of HMAC would not hold without that. HMAC's original and improved security arguments make heavy use of the ...

1

IV is not commonly used in RSA Encryption. Do you mean: AES Encryption? AES Encryption in some modes, for instance CBC or CFB uses IV (Initial Vector), which is (often) unpredictable value that never repeats for the same key. It is fairly common to generate IV randomly Random padding in RSA Encryption? There are several padding mechanisms defined for RSA ...

1

You can decript with -nopad option and check hex. Example piped command : \$ echo "hi" | openssl enc -aes-128-cbc -e -K 1001001 -iv 0100110 | openssl enc -aes-128-cbc -d -nopad -K 1001001 -iv 0100110 | hd And output : 00000000 68 69 0a 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d 0d |hi..............| 00000010

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