Tag Info

For the 3rd proposal, see my comment to the question for the issues/questions I have regarding there. For the 2nd proposal, basically what you are proposing is using an IV with a stream cipher. The IV in this case being the hash of the file which would have to be shared in order to decrypt. In theory, it is a good idea. In practice, however, the track ...

First of all, you stated: Because this message is encrypted using CBC mode, any modification of the first block of cipher text would propagate throughout the message. Actually, that's not true. Here's the CBC mode operation in the decryption direction: (Public domain image from Wikimedia Commons.) If you examine the process closely, you will see ...

Non-malleability of Scrypt w.r.t. to salt (as well as passphrase) follows from the definition of Scrypt (which simply pass that salt to that input of PBKDF2); the definition of PBKDF2 (which uses the salt followed by a non-malleable encoding of an integer as a massage passed to HMAC_SHA256); the non-malleability of HMAC_SHA256 w.r.t. the message; and perhaps ...

Yes, in theory, but this doesn't usually work in practice. You are right in that the last-block ciphertext in this example is malleable to some extent, but not as much as you seem to suggest. It is true that here, if you were to change the last ciphertext block so that the first byte of its corresponding plaintext corresponds to some value you chose, it ...

AES in counter mode works by XORing the output of an encrypted counter against the plain-text. This easily allows you to flip bits in the ciphertext and have that bit flip in the plain-text. The easiest way to get the kind of behaviour you're looking for is rather than XORing the encrypted counter against the plain-text, add it mod $2^{128}$. Decryption ...

This scheme isn't probabilistc so it could not be even CPA secure. Another weakness in this scheme is in the seed for PRG. the value "passcode"||"hashedvalue" is not uniformely distributed value. This mean that a CPA-attacker knows a part of the seed and then you cannot rely on the PRG property. A way to break the second weakness is to concatenate message ...

Your permutation idea is leaving the realm of encryption and trying to address a different type of idea: authentication. Encryption hides the bits, authentication gives confidence that they are being read as intended. But it doesn't do this properly, the attacker might still be able to flip bits. What if the random permutation maps the modified ciphertext ...

The randomness is not enough for IND-CCA-2. If we get a message (so $L$ bits of data plus the $y$ to reconstruct the random seed), we can modify it, say flip the first bit, and ask the decryption oracle for a decryption of the modified message (which will have the same $y$!), which we will get. Then the original message can easily be obtained: we get the ...

To learn more about this sort of attack, see my answer Don't use encryption without message authentication, where I detail many examples of systems that were broken because they used encryption without authentication. You will see that there is a wide variety of attacks that may be applicable, depending upon specific details of how the system works. You ...