Hot answers tagged padding
7
Well, the entire point of a cryptographical hash function is that no one can practically devise two messages that hash to the same value.
Now, the SHA family of hashes use the Merkle–Damgård construction; that is, they have an iterated hash function, and each invocation of the hash function takes as input a fixed block size (either 512 or 1024 bits in the ...
6
AES by definition takes 16, 24 or 32 bytes as key, and nothing else. If you have a different size input use some kind of KDF to transform it to the correct length.
If that input is a password this step is even more important. You should a key strengthening construction, such as PBKDF2 with sufficient iterations and a salt.
If you use authenticated ...
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 ...
5
I believe what you are seeing is that .NET automatically uses PKCS #7 padding. This will always add padding. Thus if your plaintext is a complete block length, one extra block of padding will be added.
The reason the ciphertext ends up being the same in both of your test cases is that it is adding the same padding in both cases (see PaddingMode Enumeration ...
5
RSA without padding is also called Textbook RSA.
The question why RSA without padding is insecure has already been answered
in this question.
We can fix a few issues by introducing padding.
Malleability: If we have a strict format for messages, i.e. that the first or last bytes contain a specific value, simply multiplying both message and ciphertext will ...
4
This variant of OAEP would be malleable if the underlying trapdoor permutation is malleable, and hence would not be chosen-ciphertext secure. This is a major theoretical weakness, as I explain below, and one that may lead to attacks in practice.
In more detail, suppose $G$ is the (lone) hash function and $f$ is trapdoor permutation used, so the formula for ...
4
In many existing padding schemes, without padding always being added there is a trivial second preimage attack. For simplicity let's assume a 10 bit hash function $h_{10}$ (extending this to other size hash functions is trivial).
Let $m_1=101$ and $m_2=1011000000$. I claim that $h_{10}(m_1)=h_{10}(m_2)$.
Since $m_2$ is 10 bits, no padding is needed. Since ...
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
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
How you remove padding after decryption depends on how padding was added before encryption.
Typically, we design padding methods so that it is easy to figure out exactly how much padding was added; see This article for an overview.
From your question, it sounds like the encryptor is doing zero padding (that is, adding zero bytes until the next block ...
3
I took the world's shortest look at the code, so please don't hold me to any of this. But it seems that the implementation is textbook. You provide a block of data, it gets encoded to an integer in the range 1,...,p-1 and then encrypted using standard Elgamal without padding.
There's does not seem** to be an encoding to the subgroup of quadratic residues, ...
3
This site is a reference for padding:
http://www.di-mgt.com.au/cryptopad.html
Method 3 refers to the ANSI X.923 and method 1 refers to PKCS7.
The main advantage listed is that PKCS7 allows you to double check the number of padding bytes
3
The OP wants a Key Derivation Function suitable for producing a key for the block cipher TEA, from Password and Salt. He is considering the use of PBKDF2, a common method designed for that purpose, which has a parameter controlling how slow the computation is, and thus the difficulty of password cracking.
PBKDF2 is a giant progress compared to practices ...
3
Let's say we are using PKCS#7 padding, and we'll stick to a single block message for simplicity. Modifying the ciphertext should result in an completely random decryption. To get proper padding, the resulting decryption would have to look something like this (RANDOM DATA)01 or (RANDOM DATA)0202, and so on.
Since the result is random, the probability that ...
3
You normally want to use a fully invertible padding scheme, i.e. a padding scheme with an associated unpadding scheme such that $unpad(pad(X)) = X$ for every $X$.
Assuming you only append data at the end, and don't do different things depending on the content of the message, this means that you always have to append something, even if the message is already ...
3
According to Wikipedia the purpose of adding random padding to the clear text before encrypting it is to prevent a successful chosen plaintext attack, from Wikipedia:
Because RSA encryption is a deterministic encryption algorithm (i.e.,
has no random component) an attacker can successfully launch a chosen
plaintext attack against the cryptosystem, by ...
2
If the key is too small, something like PBKDF2 should be used to expand the key to the proper size.
An authenticated encryption mode such as GCM can be used. It outputs an authentication tag which is sent to the receiver. If the decryption is incorrect, decryption will instead reault in an error or a special symbol to signify this.
P.S., normally I ...
2
1. Why do we use padding?
Both block ciphers and RSA are permutations on a block(RSA's block isn't an integral number of bytes), so it's clear that both of them need some kind of padding if the data size doesn't correspond to the block size.
With block ciphers the padding doesn't do much: It fills up the remainder of the block, and tells you how much ...
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
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
It looks fine though you are better off sticking to established standards which already have parsers written. That way you don't have any problems.
To remove the padding, read the last byte, then move that many values back and truncate. In python it would look something like this:
p = decrypt(key, ciphertext)
pad_len = p[len(p)-1]
return ...
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
We use padding because RSA is not secure without padding. See the following research paper:
Why Textbook ElGamal and RSA Encryption are Insecure, Dan Boneh, Antoine Joux, Phong Nguyen, ASIACRYPT 2000.
See also:
Attacks against plain RSA
Padding schemes
There are no particular requirements on the length of the message, except that it can't be too ...
1
If you are not planning on using your code in a deployed system, just for learning/testing (which is what you are doing right?), then zero padding is fine.
A hash function takes bits as input and outputs bits. Most software will convert those bits to something human readable (hex typically). If you want to use canned software to do the hashing (or key ...
1
Strictly speaking, it's not. But you wind up with either very complex or very ugly padding algorithms.
For example, say you were designing a padding algorithm such that there exists one string of length M that is "padded" by adding no padding at all. Clearly, it would be a disaster if any string of length less than M could be padded so as to produce a ...
1
The Input Parameter in the question is called a Label in PKCS#1v2.1; this standard states it might be empty, or be expressed in some specified syntax. I borrow Victor Shoup's explanation from Remark 3 in this paper:
A label is a byte string that is effectively bound to the ciphertext
in a nonmalleable way. It may contain data that is implicit from
...
Only top voted, non community-wiki answers of a minimum length are eligible
