# Tag Info

## Hot answers tagged block-cipher

5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...

4

The obvious answer to your question is "yes". The kernel mode implementation pointed to by otus clearly shows that it can be done. That it can be done doesn't mean it gets done however. Many Google searches for sourcecode don't show any OpenSSL code that implements this functionality. In general, OpenSSL doesn't rely on the crypto code of the kernel. So, ...

4

Some amount of known or controlled plaintext is clearly required for the attacker to get the block cipher output. Actually, that's not much of an issue; we can often get a reasonable amount of known plaintext from real encrypted messages. In fact, the known plaintext for each message doesn't have to be the same, and you don't have to have completely ...

4

One of the basic security requirements of a block cipher mode of operation is that it is indistinguishable under chosen plaintext attack (IND-CPA). Essentially, this means that, if an attacker chooses two messages $m_A$ and $m_B$ and the defender randomly returns either $\text{Encrypt}(K, m_A)$ or $\text{Encrypt}(K, m_B)$ (with $K$ kept secret from the ...

4

What you are looking for is a definition of PEM, privacy enhanced mail. Obviously PEM is not just used for mail anymore. The definition of the header lines seems to be best described by section 4.6: "Summary of Encapsulated Header Fields" of RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication ...

2

If you want to construct a PRF for arbitrarily-long inputs using AES, then just use CBC-MAC (while prepending the message length in the first block). I don't see any advantage in what you are proposing and therefore don't see any point in trying to analyze something non-standard.

1

Remember that the initial value is split into two halves, and each half is shifted independently. If all the bits in each half are either 0 or 1, then the key used for any cycle of the algorithm is the same for all the cycles of the algorithm. This can occur if the key is entirely 1s, entirely 0s, or if one half of the key is entirely 1s or the other half is ...

1

You do not get semantic security; a chosen plaintext attack can (with high probability) distinguish this mode from random. Consider the case where you are encrypting a two block message $(B, B \oplus 1)$ (for an arbitrary value B). Then, if IV (which I assume is selected randomly) happens to have an lsbit of 0 ($p = 0.5$), then the two ciphertext blocks ...

1

In essence it seems to be a sort of mixture of CFB and CTR. I see a possible issue where encrypting sequential values will show up as repeating patterns in the ciphertext. Consider the following 4 bit example. $$PT_0 = 1010$$ $$PT_1 = 1011$$ $$PT_2 = 1100$$ $$PT_3 = 1101$$ $$IV = 1110$$ Assuming $PB$ is the plaintext block directly before encryption. ...

1

I am afraid there are no efficient methods of knowing the padding methods deployed unless it is specifically provided by description from whomever authored the original codes. You have to try bruteforcing the padding scheme to estimate what padding schemes are used.

1

As fgrieu hints at in the comments, it is not in general possible to find $\operatorname{Enc}$. Otherwise you would be able to break an arbitrary block cipher, because the key of any block cipher can be cast as part of the algorithm instead. Even if you ignore the computational cost, there is no way to find $\operatorname{Enc}$ given values for only one ...

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