New answers tagged

8

You would not just need a mode of operation for what you're asking. What you need is a secure transport protocol. Probably the best well known one for TCP connections is TLS of course. For UDP connections you could use DTLS. If you have a shared key you could use one of the pre-shared key (PSK) variants. If you want to create your own transport protocol you ...


1

It depends on the position of the two interchanged bits. Assume they have different values, i.e. one is $0$ and the other is $1$. Indeed, if they had the same value, interchanging would not affect plaintext decryption. Let's say $n$ is the length of every block. In CBC, every ciphertext block is involved in two plaintext blocks decryption: its own and ...


9

I would pick e) none of the above. None of those modes offers integrity protection, so unless integrity is handled elsewhere, your application is wildly insecure. An attacker could modify bits in transit and do nefarious things. Of the three, CFB and CTR are the worst for the application and should be very easy for an attacker to mount successful attacks, ...


1

Here is an example of a proof. This proves why CBC mode needs an IV that is random: (fyi many people think a nonce will suffice, but it won't, it needs to be random) Our definition of a probabilistically secure encryption scheme: Imagine two oracles taking two inputs: a plaintext $P$ and initialization vector $IV$. The 1st oracle $Enc_{k}(P, IV)$ performs ...


0

You can use CCM or EAX mode. EAX mode is not standardized by NIST, but it uses AES + AES-CMAC as underlying primitive, implementing a secure authentication mode. You could use AES-CMAC (or EAX mode without any ciphertext and just Additional Authenticated Data) to calculate an authentication tag over the authentication tags of the blocks. Advantage of EAX ...


0

To answer your ideas of: "I use hash-then-encrypt" with CBC + SHA-1 "I use MAC-then-encrypt" with CBC + HMAC "I won't use GCM because of unclear usage guidance" First, hash-then-encrypt is a really bad idea. You really should avoid it if possible. Details are explained in this related question on Crypto.SE. Second, MAC-then-encrypt is a concept you also ...


1

Assuming that there are no collisions and there exists a 1 to 1 bijection between input and output, you could construct and store a table of assignments on a single round of encryption for all 256 possible bytes regardless of the key size. From there you can extend this to subsequent rounds by simply XORing the result of the previous round to the next 8 bit ...


0

not possible if it's CBC hidden. Try using pairs and put them in dictionarys. Bruteforce is also a way but not answering the question properly.


1

It's also worth considering the point of a MAC in the first place, i.e. - why it should be calculated over all of the input rather than just the first block. Making the tag dependent on only the first block of the tag would allow an attacker to fill in the rest of the message with whatever they wanted, so long as the first block of CT represented a valid ...


13

The MAC value should be calculated over all of the input, not just the first block. The chaining of CBC makes sure that the bits in the last block of ciphertext depends on all the previous blocks.


0

Consider the following chosen-plaintext attack on the modified CBC-MAC function: Send $m_1$, $m_2$, $m_3$, receive $t_1$, $t_2$, $t_3$. Send $m_1$, $m'_2$, $m'_3$, receive $t'_1$, $t'_2$, $t'_3$. Send $t'_2 \oplus m''_3$, $m''_2$, $m''_3$, receive $E_k(t'_2 \oplus m''_3)$, $t''_2$, $t''_3$. Then you know the following (message, tag) pair will verify: ...


3

As you know, it makes reading and writing the disk very slow if all the data in the drive is chained together. If so, writing to a drive of size $n$ at position $p$ will require $\Theta (n-p)$ time. One solution is the drive being divided into sectors, and each sector being chained. The IV of each sector can be attained using ESSIV. it generates IVs from a ...


1

The "XOR cipher" described does not encrypt more than the first block, even if you do not reuse keys. The subsequent blocks can be "decrypted" by the attacker simply by undoing the XOR – there is no secret involved. Decrypting the first block and finding the key does require more than one message. It is a case of the many-time pad and can be solved either ...


2

No, you're not weakening your data in that case. You could even use ECB in to encrypt random data. Symmetric key wrapping often just uses ECB. But beware that it depends on how many bytes you encrypt. You may want to make sure all bytes are random (if you know the plaintext size in advance). Think about encrypting a single random byte and filling the rest ...



Top 50 recent answers are included