Hot answers tagged padding
10
I recommend that you stick with the standard padding methods, even in your scenario.
Here's one reason, if your 'random password' consists only of the AES key, and you use the raw RSA operation on it (that is, zero pad it to the size of the RSA modulus, and then compute $M^e \bmod N$), then yes, there does exist weaknesses; there's a meet-in-the-middle ...
8
Padding None can be used with stream cyphers and AES-CTR in order to keep the cyphertext the same length as the plaintext. Padding Zeros cannot always be reliably removed, and so should be avoided. Any of the others can be reliably removed and are fine for use.
Padding None leaks information about the length of the plaintext. Apart from that there is no ...
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 ...
7
Well, there are no necessary 'reduction in strength', for two reasons:
You ask about how many signatures you'd need to recover the private key. Well, even with unrestricted Oracle access to the private operation, there's no known way to recover the private key (or equivalently, factor the modulus) that's more efficient than just ignoring the Oracle and ...
7
MD5, like other hash functions, uses the Merkle-Damgard construction. You take the message and break it up into fixed-size blocks. You start with an intialization vector (IV), which you feed into a compression function along with the first block. Take the output (it will be the same length as the IV), and feed it into the compression function along with the ...
6
The Merkle–Damgård hash construction customarily pads the message $M$ to be hashed with a single bit set to 1, a minimal number of bit(s) set to 0, and the representation of the length of the message in binary over some fixed number of bits. The padded message is then formed of a number of blocks $B_i$. The hash is computed by repeatedly applying a ...
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
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 ...
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
Indeed, ISO 10126-1:1991 and ISO 10126-2:1991 titled Banking -- Procedures for message encipherment (wholesale) have been withdrawn circa 2007.
The padding specified by ISO 10126 was adding random until the message has length 7 (mod 8) bytes, then adding a byte coding the number of bytes added (including that byte), making the length 0 (mod 8) and suitable ...
5
One thing you can do in this scenario, if you really don't want to use padding, is to use key encapsulation (RSA-KEM) instead.
That is, instead of first generating a random AES key and then padding it to the full RSA message length, you instead generate a random RSA plaintext and then derive your AES key from that using a suitable KDF. Since the RSA ...
5
One of the more straight forward attacks against RSA is when the encryption exponent and the integer encoded message are both "sufficiently" small values. It is possible that the ciphertext $c = m^e$ will be less than the modulus $n$. This would mean that $m^e$ is directly encoded as the ciphertext and then easily factored since it doesn't take advantage of ...
5
From what I understand, you consider a scenario in which a fixed, random-looking message $M$ is sent to multiple recipients, encrypted using RSA with some padding (this is called the "broadcast RSA" setting).
Moreover, you consider affine paddings, in the sense that you apply the RSA function to an element of $\mathbb{Z}_N$ of the form $a_i M + b_i$ for ...
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
The simplest and strongest security proofs for RSA-based cryptosystems are when the padded message is random-like on $Z_n$. None of the proposed scheme does that.
At the very least, it is prudent and customary that the bit size of the padded message approach the bit size of the public modulus $n$. With 256-bit $M$, padding as $\mathrm{SHA256}(B_{pub})||M$ ...
4
If you pad a 128-bit value $K$ with zeroes to the left, and interpret the value numerically with big-endian convention (as happens in PKCS#1 in general), you end up with a value which is no greater than $2^{128}$. If the public exponent is $e = 3$, then the "encrypted value" is no greater than $2^{768}$, and no actual modular reduction takes place. ...
4
There is a beautiful characterization for the collision preserving padding rule of any Merkle–Damgård-construction: the padding rule should be suffix free. See the 2009 paper Characterizing Padding Rules of MD Hash Functions Preserving Collision Security by Mridul Nandi for more details.
The length of the message, as it turns out to be, is the simplest ...
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
Well, that is exactly how RSA signatures normally work. PKCS#1 version 1.5 block type 1 is the most common signature format used today. For block type 1, the padding is a constant string, and the data is the hash packaged in an ASN.1 structure that also identifies the signature algorithm.
More modern signature schemes incorporate a random component, but ...
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
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
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 ...
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
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
