# Tag Info

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

If we note $|m|$ the number of bits in the bytestring coding the message $m$, the first padding considered is $m\mapsto \tilde m=257\cdot2^{|m|}+m$, and the signature is $m\mapsto\tilde S(m)=S(\tilde m)=\tilde m^d\bmod N$, where $S$ is the textbook/naked RSA signing $m\mapsto m^d\bmod N$. Notice that for any $m$ small enough that $m^2$ can be signed, we can ...

4

The problem is not with compression and encryption, it is with the protocol that is being used, and the type of data being compressed (or not) prior to encryption. The most damning leaks are on protocols that were either designed to be compressed without encryption, or encrypted without compression. The best example I have is VOIP systems that use a ...

4

Yes, there is an attack that has a fair chance of success, like $2^{-8}$ per $Sign$ (and perhaps $Sm$) submitted; or even more depending on exactly how the encryption padding is removed/verified. The attack does not require submitting a message for signature to a party knowing the signature private key. I consider the attacker successful whenever she manages ...

3

First of all, a more usual padding scheme would add 5 times the same byte 0x05 (in your example) so the check not just removes 5 bytes, but also checks that the 4 bytes before it have the same value. But let's assume your scheme (which is underspecified: what to put in the bytes before? Zeroes, or random values?) for now. What if you cannot remove that ...

3

RSA-OAEP is an encryption scheme that is CCA secure in the random oracle model (http://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding). You are talking about encrypting/decrypting hashes with some private/public key, but I don't think you're actually talking about encryption schemes. What you probably mean are digital signature schemes ...

3

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

3

You can decrypt with the -nopad option and check the HEX output. 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 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 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 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 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

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 This is not padding, nor is it related to the concept. The output from the bcrypt library you're using is in a format inspired by Linux crypt(3) format. Dollar signs are field separators. 2a is the algorithm identifier. The full list is: ID | Method ───────────────────────────────────────────────────────── 1 | MD5 2a | Blowfish (not in mainline glibc; ... 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 ...

2

In general we nowadays use fixed paddings or a stream mode of operation such as CTR. Authentication tags are usually used to validate integrity/authenticity. Examples of authentication tags are those created by calculating a MAC or HMAC over the ciphertext and additional data such as the IV. In general known plaintext - including the padding - should not ...

2

Your suggestion is essentially what ISO 10126 does, since there's no way to verify the random bytes that make up the rest of the padding. You could do the same with e.g. PKCS #7 padding, as you suggest. However, this would leave a covert channel. If those other padding bytes are not verified, they can be chosen by the sender and even modified by an attacker ...

1

With byte aligned data, bit padding allows the padding oracle attack. Every message has to end in a 0x80 byte followed by any number of zero bytes. You can iterate one byte at a time just like with many other byte paddings. If you allowed plaintexts that are not a full number of bytes long, the attack wouldn't be possible. (Every plaintext that didn't end ...

1

I don't think you will be able to "brute force" decrypt your data. The AES key and IV a probably chosen randomly to encrypt the actual data using some encryption mode. As there is an IV, as you state, it will not be ECB but probably CBC. To get the AES key and IV you need to know the RSA private key D. If the the RSA key pair is chosen carefully, you are ...

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

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