Hot answers tagged

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.


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


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


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


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


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


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


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


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


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



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