Hacker News Reader

Comment by turtles | Hacker News Reader

In the TLS handshake: "The server generates its own hash, and then decrypts the client-sent hash to verify that it matches"

The server decrypts a hash? But thats not how hashes work.

View on HN

The client encrypts its hash before sending it to the server. Thus the server must decrypt it to compare it to the one it generated.

Hashes are one-way, so cannot be decrypted. The server can _compare_ the results of a hash (by doing the hash itself, and comparing the results), though.

I can create a SHA-256 hash, then encrypt it with AES. You would then have to decrypt it to read the hash inside is what the parent is saying.

You and turtles are suffering from the cryptographic equivalent of a hypercorrection, in the same way that well-intentioned people insist on the propriety of the grammatically impossible phrase "between you and I" (which should be "between you and me," because prepositions take objects, not subjects.) The two of you have had the irreversibility of one-way hashes drilled into your heads, just as many of us were taught when young not to say "me and Susie were playing on the swingset." And you have an allergic reaction to anyone using "decrypt" and "hash" in the same sentence, which can lead to that allergy triggering a false positive. In this case that's what's happening.

Cryptographic hashes are irreversible. That's the point of such a device. But there is nothing stopping someone from taking the result of a cryptographic hash and then encrypting it, and then that someone or someone else decrypting that ciphertext to recover the hash result. E(H(S), k) leads to an encrypted hash, and D(E(H(S), k), k) recovers the hash. It's computationally infeasible to retrieve S. But nobody wanted to do that; they just wanted to know H(S).

You are correct that the server compares the result of the hash (which in context can also be called a "hash," such as "I used SHA-256 on my term paper, and then I spray-painted the hash on the face of the town clock tower, thus proving the existence of my term paper before the class deadline"). Nobody's arguing that. But how did it obtain the thing it's comparing its own result to, without M also obtaining that thing?

(I'm actually not sure whether TLS sends the actual hash or bases subsequent computations on the assumption that both sides can independently derive it. But if it does the former, it's totally fine to say "it decrypts the hash," which is the objection of the parent of this thread.)

Thanks, TIL :)

Most of that description is outdated and/or wrong. Probably this HN article should say (2015).

But yes, of course you can decrypt an encrypted hash, this way you get back the plain hash.

The client calculates a hash, it _encrypts_ that hash, and sends it to the server, the server _decrypts_ it, and then can verify that it has the same calculation.

The reason this is done is that it can detect a situation in which the client and server were persuaded to arrive at the same results by different means, whereupon they should abort the connection. The mechanism in TLS 1.2 and earlier was not very good, a better one is included in TLS 1.3 but alas last I looked it is disabled in popular browsers because it's incompatible with yet more middlebox crapware from "security" companies.

It should read "then compares the generated hash to the hash that was received from the client to verify that it matches"

Or something along those lines.

I assume the reason for doing this is to confirm the symmetric key now in use is known between both parties?

I wrote it above, but more relevant here maybe: No. There's no need to confirm that, if the keys don't match everything will fail anyway and the connection aborts because everything either party sends appears to be gibberish.

The description linked over-simplifies, the hash they're calculating is a summary of the handshake process by which keys are agreed, we want to prove that both saw the _same_ process happen to reach this state.

Suppose I am willing to use archaic method A because I'm a simpleton, although I do know methods C and E which are safer. The wise people running www.google.com only allow method A if you don't know methods B, C, D or E.

Now, I try to connect to www.google.com and unknown to me a Bad Guy is in the middle. I say "Hello, I know methods A, C and E", but the bad guy changes that message to say "Hello, I know method A only". Google replies "OK I guess we can do method A then" and we use method A. The Bad Guy knows how to break method A and now my security is ruined!

But with this Finished message in TLS, www.google.com and I will calculate different hashes, since I know I said "I know methods A, C and E" but www.google.com got a message from me saying "I know method A only" and those don't hash the same.

This proves somebody is tampering with our connection, we must abort.

ah, cheers.

Reply on news.ycombinator.com