# Tag Info

7

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

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

6

The 16-byte IV and ciphertext (which together are part of the output of $e_m$) are assumed to be intercepted by an adversary. That reveals the number $b$ of 16-byte blocks in the ciphertext. With CBC and PKCS#7 padding, $b=\big\lceil{{n+1}\over16}\big\rceil$ where $n$ is the byte size of the plaintext (the file size). Putting $n$ itself in a header thus ...

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

No, it is not a problem to have the same padding at the end of a message. Some known plaintext is often available in practice (protocol fields, etc). The security of the system is (or at least should be) based entirely on the key. If you are really worried about it for some reason just change the IV for each 64-byte block. Or as CodesInChaos said in a ...

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

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

3

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

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

The answer is correct, you don't need to unpad the message. When/if you verify the signature, simply check that $(\text{signature})^e == \text{pad}(\text{message})$ Regarding the padding scheme, you can just use a full domain hash. Here's how you implement a full domain hash:  \mathrm{cycles} = \frac{\text{(RSA key length)}}{\text{(SHA digest length)} ...

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

Not a complete answer, but since you mentioned "unmodified RSA" I feel it's relevant. Something stronger than vanilla RSA is necessary, even if it isn't semantic security. Example: What if you have a public key exponent of 3 and the symmetric key being encrypted is 16 bytes long? Using raw RSA, $m^e$ would be about $128 * 3 = 384$ bits long and thus ...

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

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

2

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

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

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

Padding in cryptography means adding a (mostly secret) random set of data to the cryptographic functionality. In practice and when done correctly, cryptographic padding adds a cryptographic problem and thereby reduces attack vectors because (theoretically) it reduces the success in “guessing” intermediate or final states of the encryption and/or decryption ...

1

I take the question as: how to make a chain of RSA encryptions with distinct public keys $(N_j,e_j)$, that is $D_{j+1}=\operatorname{RSA-encrypt}((N_j,e_j),D_j)$, without having the ciphertext size growing at each encryption? I'll use two facts: When plaintext $x$ behaves to an adversary about as a uniform non-negative random number less than some bound ...

1

Counter mode (CTR mode) seems like it will do what you want. The length of the output is equal to the length of the input, plus the length of the IV. If this is not what you want, you'll need to explain your question/requirements more clearly. In practice, I recommend you use an authenticated-encryption mode, such as EAX or GCM etc.

1

Generally sockets (or at least, sockets that use some kind of transport layer like TCP) get closed. So you are at the end when the stream of data is at its end. So you do the unpadding then. Except that without MAC or authenticated mode of encryption you are extremely vulnerable to e.g. padding oracle attacks. If you want to send the size of the data in the ...

1

I'm not really familiar with blind signature schemes, so please take the following with a grain of salt, but what you describe looks like a really funny way to apply padding. Normally, one would pad the message (using a suitable padding scheme like RSA-PSS) before the first RSA operation, i.e. $\text{padded message = pad(message)}$ \$\text{blinded message ...

1

Adding to David Cash's answer, besides SAEP and SAEP+ by Boneh, there is another paper that improves OAEP using only a one-round Feistel structure and has an additional feature: redundancy-free encryption (which none of OAEP, SAEP and SAEP+ have). Read Veriﬁed Security of Redundancy-Free Encryption from Rabin and RSA by Barthe, Poitcheval and Beguelin ...

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