# Tag Info

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

4

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

4

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

4

It uses deterministic padding, i.e. padding with FF octets, finalized by a single 00 valued byte. So it is indeed RSASSA-PKCS1-v1_5 which uses EMSA-PKCS1-V1_5-ENCODE. Don't be fooled by the reference to RSA encryption in the OID for sha256WithRSAEncryption. That simply points to the modular exponentiation - in this case with the private key. PKCS#1 versions ...

4

Does AES-CBC always use PKCS#7 padding? No. Other common or plausible paddings include No padding, where the plaintext's length is known to be a multiple of 16 bytes. Bit padding, where the plaintext is considered a bit stream, it is appended a bit at 1, then 0 to 127 bits at 0 to reach a block boundary. With big-endian bytes, that's appending a byte at ...

3

In my specifications, it doesn't matter if someone can decipher the messages. However, someone should not be able to send encrypted messages that would be recognized by the recipient. If that's the case, then encryption is the wrong solution; you are looking for a Message Authentication Code (MAC), such as CMAC. With CMAC, you hand the message and the key ...

3

The maximum payload for each encryption using RSA OAEP is displayed here. For any message up to that size a complete RSA operation needs to be performed. Of course, if you encrypt each byte separately then you won't get much performance, and your ciphertext will expand enormously. You need to make sure that you use the entire possible payload for each ...

3

Yes, this is expected, if the RSASSA-PSS signing code/test uses salt the width of the hash, which is customary. In that case, a $h$-bit hash (with $h$ multiple of 8) requires an RSA public modulus at least $2h+9$ bits. That's semi-clearly stated in PKCS#1 v2.2, section 9.1.1, condition on enBits, with actual test in step 3. That's because the message ...

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

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

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

2

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

2

The padding method for SHA-256 is (assuming you're byte oriented - it appears you are) is 'append an 0x80 byte, and then add 0x00 byte's until the length modulo 64 bytes is 56. This implies that if the original message length modulo 64 is 56 or larger, you'll need to do one more hash compression operation. That means that your computation of the number of ...

2

No, it is not the output size of the PBKDF2. The problem is when you enter an incorrect password the PBKDF2 generates an incorrect key for you with the correct key size. When you perform decryption of the ciphertext, the library will test the validity of the PKCS#7 padding on the plaintext. Since the key is incorrect you will get a garbage message with the ...

2

Is step #3 (verifying the EMSA-PKCS1-v1_5 padding) important to the security of the system? Yes. That's paramount for small RSA public exponent $e$. For $e\in\{3,5,7\}$, the easily computed integer $s=h^{(e^{-1}\bmod2^{254})}\bmod2^{256}$ is an acceptable signature for any message with an odd SHA-256 hash $h$ (that is about one message out of two). The ...

2

For this answer I'll be focussing on solely on RSA (the RSA tag is present, so I'll suppose that this question is just about RSA). It is also the most likely signature scheme that requires padding, I suppose. TL;DR: you don't just need to know the padding scheme in advance, but also the other configuration options to be used, such as data hash method and ...

2

Lets assume Java here. In that case the ECB part of the name is a misnomer. ECB is the most simple mode for a block cipher. It means splitting up the plaintext message into multipe blocks and then encrypting them separately. Java's RSA implementation doesn't split anything up, you can only encrypt a single block of plaintext. They should have used "None" ...

2

I have to encrypt 64-bit messages and then send them as a 64-bit message as well. I can't afford to send more than one 64-bit encrypted message for one 64-bit unencrypted message. If that is the case, then the security that you can achieve is rather limited; you'll have to accept those limits, or find a way to allow some ciphertext expansion. One thing that ...

1

I assume this is homework (I have time imagining that this is a problem that you need to solve; if it is, turn "use real RSA padding"). Since this is assumed to be homework, I'll give you the initial steps, and let you do the rest of the work. First off, what you're asking is to find a value $m$ such that \$(m^3 \bmod n) \bmod 2^{136 } = \text{"\x00"...

1

The first 10 lines can be replaced with uint64_t blocks = (len+72)/64; and that will fix the code for the example at hand (as well as extend the message capacity if int is 32-bit and len is 64-bit, which can't be told from the code¹). My mental process to construct (len+72)/64, which works for many things in crypto that divide things into equal size blocks, ...

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

I've read several texts which say that if the entire plaintext is a multiple of the block-size padding is not required (and not using padding would not mean a loss of security). I generally disagree on this. In modes where padding is used (e.g., CBC), padding is mandatory. This is per spec. Not including the padding is simply not an option. In some ...

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

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