I'm taking a course in information security and I have many unanswered questions!

I've learned that encryption doesn't guarantee authentication, which makes sense to me, but all the examples in the lecture and the ones I've found on Google seem very artificial or theoretic to me. For example one example was, that the attacker could modify some bits in the cipher text to increase or decrease the amount of money that need to be transfered. But how should anyone know the exact position of the bits representing this amount? Could anyone provide a more realistic example or explain why this is realistic?

A second question is about authentication with hash functions. For example when I download linux mint, I verify it with md5 (why do people still use md5, although it's considered completely broken?). So if anyone would make a MITM attack and forward a malicious distribution to me, I would notice it. But lets assume the adversary could find a collision in any of those secure hash functions. Then it doesn't help him, because he wants to modify the distribution in a special way, not just find another iso image that has the same hash value as the one provided, right?

I know there are already lots of questions regarding this topic, but I haven't found a link that satisfies me :-)



We must assume they do. That is, the system should be secure even if they happen to know the format.

For common protocols, like HTTP, it's easy to see that everyone knows what is where. The site-specific data might change, but if the attacker can create an account for themselves, they can see legitimate traffic. Even for less common protocols, we can't usually fully guard the protocol specification from an attacker. For interoperability reasons, it might actually be public, or available for money. Or some insider could leak it, etc. Anyone working with the protocol or the systems using it would be in the position to find out what the format is.

Rather than keep the whole protocol secret, it's easier if the security is based on only the security of the keys.


Well, maybe. Unless you got the hash from the same server as the installation image, where the attacker could of course modify both. A pure hash isn't much of authentication, since anyone can calculate a valid hash for a modified file. You should use a (public key) signature system for verifying software downloads. (Or rather, for verifying the hashes.)

As for collisions, creating a collision might be hard if you know the source data is two lines in iambic pentameter, but as @zlk says, an ISO file likely has lots of extra space to work with to create the collision. That is, if the base installer can be modified without you noticing, it doesn't matter much if some optional packages on the image get trashed to accomplish it.

  • +1 for the line "We must assume they do. That is, the system should be secure even if they happen to know the format." Brilliantly drives the point home about what makes secure algorithms secure, and why supposedly secure systems like the enigma machine were compromised. – Verbal Kint Aug 9 '16 at 19:52
  • naively I just thought of a long bit stream, but of course since there is some protocol involved I see that it's not that unrealistic... so this kind of follow from the kerckhoff principle "the enemy knows the system"... on the other hand it seems that many don't follow this principle (like the NSA etc, since they don't make their systems public) – ph0t3k Aug 10 '16 at 7:20

Encryption: The reason encryption isn't authentication is because each party doesn't have a way to determine who they are talking to without authentication. Based on the example, the attacker could impersonate one party and have the money transferred to a different account entirely.

Hash functions: md5 is broken, but it is still difficult to create a forged file that can be used in place of the original one. That said, an iso is one of the easier file formats to forge because the attacker can add arbitrary data to generate the colliding hash without breaking the file format.

Also, many places publish sha1 and sha2 hashes. Use those instead, preferably the sha2 hashes.


First, the property that you're talking about in both cases is not in fact authentication, but integrity. A MAC does provide both authentication and integrity checking, but in the specific instances you've cited, it is integrity that is at issue.

For the example of a using a MAC for authenticated encryption, the example you cite is true...When encrypted data has a well-known structure (as it often does) and the plaintext is known, it ciphertext bits (or the IV) can be tweaked to change the decrypted message. A far more common attack against unauthenticated encryption however, is a padding oracle attack against block mode ciphers. which can lead to complete loss of confidentiality. Properly protecting the integrity of the ciphertext with a MAC in an encrypt-then-MAC construction can completely eliminate the possibility of these attacks.

For the second example of MD5, the reason that MD5 is still used is primarily inertia. It's implemented in a lot of places, been used for decades, and it's hard to motivate change, even though SHA-2 is certainly better. That said, there is no practical attack here. MD5 is broken in respect to collision attacks, but what you need for this particular attack is not a collision, but a second pre-image. This is much harder, because whereas with a collision you only care about finding two inputs, any two inputs, that produce a single output, with a second pre-image attack both the first input (the legitamate file) and the output (the hash of that file) are fixed, and only the second input (the malicious file) can be manipulated. The best known pre-image attack against MD5 right now has a cost of something along the lines of 2123...Far beyond what is technically feasible. So, no matter how hard an attacker may try, they will never be able to produce a file with a signature that matches the existing signature of an existing file.

  • But the example of the money transfer is also an authentication problem, since you want to know, who is transfers money to whom, isn't it? But then it's kind of wrong to say that MD5 isn't secure anymore? (now I also understand the difference between collision resistant and 2nd pre-image attack, thanks :-) – ph0t3k Aug 9 '16 at 18:00
  • @ph0t3k While you do want to know that the message is authentic, that's not the point of the MAC in terms of preventing the message from being modified by a malicious individual. Also note that authentication in this example is not necessarily (or even likely) authentication of the account holder for which the money is to be transferred, but authentication of data origination, in other words, authentication of the bank system that encrypted the message. – Xander Aug 9 '16 at 18:06

Your Answer

