HTTPS explained with carrier pigeons (2018) | Hacker News Reader

HTTPS explained with carrier pigeons (2018)

baida.dev

95 pointssigna1118 comments

There was a video of someone describing cryptography during a lecture with the example of a secret locked by Alice and sent to Bob. Bob has no way of opening Alice’s lock, so they simply add their lock and send it back to Alice. Then Alice removes her lock and sends the secret back to Bob, who now can remove their own lock and access the secret.

What kind of cryptography is that? Does anyone know what lecture that was?

Public Key cryptography (e.g., PGP, TLS, SSH)

What you described is the goto illustration used for PKI

https://en.m.wikipedia.org/wiki/Public-key_cryptography

GP's description looks more like DH Key Exchange.

https://upload.wikimedia.org/wikipedia/commons/thumb/4/4c/Pu...

That exact image is found in the link I shared, with additional detail :)

I sourced it from your link. I disagree that the above commenter is describing "PKI" and is specifically describing "DH Key Exchange" as evidenced by the image linked from the article you referenced.

Not exactly as you describe, but very similar and still a good explanation of simple key exchange is [1]. However I believe (Its a long time since college for me...) Diffie Helman as mentioned elsewhere is a bit more complex [2].

[1] https://www.youtube.com/watch?v=U62S8SchxX4 [2] https://www.youtube.com/watch?v=pa4osob1XOk

It's perhaps not exactly what you mean, but the paint example of Diffie-Hellman is pretty neat for coming up with a common secret: https://cdn.comparitech.com/wp-content/uploads/2019/03/diffi...

> What kind of cryptography is that?

It isn't. That is an example where a physical system that would work[‡] does not when applied to mathematics, given as an example where physical world analogies do not translate to useful mathematical methods. It is used as part of the journey towards understanding remote key exchange and public key cryptography, such lectures usually follow the rough pattern:

1. That two-lock physical method is described, which won't work because there is no mathematical operation that can be applied and removed out of sequence like that which is also both not trivial to break/brute-force and doesn't require a pre-shared value which defeats the objective (if you can arrange to securely share that value then you can use that method to share the original secret).

2. But, what about modulo operations? Goes on to show how rotating through a prime modulus might have the same effect, pushing through to explaining a key exchange scheme like DH (where there are pre-shared parameters, but they do not need to be secret). Both parties end up with the same key without ever transmitting it, and can use that to encode the actual message(s).

3. But, key exchange like that, while effective and sufficiently difficult to crack assuming good parameter choices, relies upon both parties being in current contact or the latency is very high as it takes a few back-and-forths to decide the key that will be used to encode the message. What if I want to send a message to you right now, that you can read as soon as you receive it, without having to wait for you to be online so we can derive a secure key first?

4. Goes on to describe the scheme R, S, & A came up with (as did another group in GCHQ a little earlier, but their work was classified for decades so very few knew about it) using public & private key pairs and clever† application of co-prime numbers and modulo arithmetic, and the birth of public key encryption and signing.

[‡] ignoring the round-trip latency, and the need for truly indestructible boxes and locks!

[†] it might not seem so genius now as we've known about it for nearly half a century and other schemes are supplanting it, but it is one of those ideas that are relatively obvious once explained but not at all easy to come up with from scratch

> 1. That two-lock physical method is described, which won't work because there is no mathematical operation that can be applied and removed out of sequence like that which is also both not trivial to break/brute-force and doesn't require a pre-shared value which defeats the objective (if you can arrange to securely share that value then you can use that method to share the original secret).

That isn't exactly the issue. The key sharing problem is unavailable in both meat-space and math-space and so is irrelevant in context (it applies just as well to the physical locks). With key sharing not a concern, all you need is for your locks and keys to be commutative. That's easy#1 to do securely.

#1 Basically all "secure" cryptography other than a one-time pad is reducible to a "hard" problem, but last I checked those hard problems may have vulnerabilities we haven't discovered. Nobody has proven any of those techniques actually secure. However, that would be a criticism of all modern cryptography, not just commutative locks.

I think some of the current work on encrypted databases might wander into this territory.

I can't recall if symmetric ciphers are commutative or not. Specifically if:

    f(f(x)) = x 
    g(g(x)) = x

are there cipher systems where

    f(g(f(x))) = g(x)

because that's essentially the problem here. Any other encryption method would require Alice to know Bob's key, or is more easily solved with public key cryptography, where Alice just encodes the secret with Bob's public key and sends it to him.

Sounds like you're describing a three-pass protocol: https://en.wikipedia.org/wiki/Three-pass_protocol

Note that this requires the encryption to be commutative - in the third step Alice has a message in the form e_B(e_A(msg)), where e_B and e_A are Bob's and Alice's encryption functions. Alice must be able to apply her key to obtain e_B(msg), removing the inner encryption. This can be achieved with some modular exponentiation magic.

I don't know of any practical applications of this, probably because it requires both parties to be online at the same time, so they may as well use the simpler Diffie-Hellman key exchange.

I like these sorts of articles. Sometimes you just need to understand what's happening without going into the real detail. I've always learned best when there's an ELI5. I used to prefer the for dummies and idiots books for exactly this reason.

A good introduction to HTTPS for beginners, you should write an article just on cryptography and how that can be built.

Neat; but if I were non-technical person, the next question I would ask would be, why can't Mallory just forge Ted's certificate and use that to fool Alice or Bob? In this scenario, Alice or Bob would receive a box which has a certificate which looks very similar to what they remember Ted having.

What would be a good non-technical metaphor for that?

In reality of course, we use trustworthy browsers such as Firefox which (relatively invisibly) enforce certificate validity for us. I'm wondering where that would fit in the metaphor.

Unfortunately it does not load images (Vivaldi, Linux, adBlock). JS enabled/disabled makes no difference.

Pity :-(

I'm glad to see that people are willing go even longer distances than me for a practical joke. Unrelated, but this must be the only wikipedia page I know of that contains a joke.

You should also see https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_... as another such Wikipedia page.

From: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...

Reply on news.ycombinator.com