Hacker News Reader

Hacker News

Comment by ChuckMcM | Hacker News Reader

Parent Full thread

ChuckMcM

I had a discussion once, back when I was wearing a crypto hat, which went like this:

Me: "Yes triple-DES is reasonably secure, how do you exchange keys?"

Them: "That is part of the connection setup."

Me: "Great, how do you protect the keys during setup?"

Them: "What do you mean?"

Me: "What form of encryption do you use when you're doing the setup, and sending over the keys?"

Them: "Well we really can't encrypt the setup part, after all we haven't even set up a connection yet."

Me: "Ok, and thanks. Now move along, we'll call you..."

View on HN

A closer to home example:

This is how the top comment starts on the HN thread about the ZLL master key being published, two years ago:

"This may not be much of an attack. The master key is used only during "commissioning", when a controller is introduced to a light."

[1] https://news.ycombinator.com/item?id=9249753

Trying to learn some more about crypto, what sort of answer would you be looking for? Would Diffie-Hellman be appropriate?

Yes (and no). Asymmetric which is based on key pairs (generally one public and one private) allow you to pass around a key that can be intercepted without compromising your ability to communicate securely using the key your didn't pass around. That said, it is always important to be attuned to whether or not those keys can be compromised by "brute force" or through a weakness.

So the vendor who is thinking about it, would have told me about their public key system which is used in the initial transfer to protect the secrets. Then they would have described how they can upgrade and change keys over time as attackers gain the upper hand on various bit lengths, and how the elements of their system that depend on randomness, do so without being susceptible to a birthday attack or an algorithm attack on their PRNG.

When they do that, I know they've been thinking seriously about how such systems are built and deployed and there is some hope that doing the do diligence "deep dive" will show me a solid system.

And one part that is often forgotten: How to authenticate the other side.

Without authentication asymmetric encryption is still useless, because someone could man-in-the-middle your key exchange, swap out the public key that is sent both ways and make either side think they now have a secure channel with each other while in reality they have a secure channel with the man in the middle.

So the challenge is that they'll need some equivalent of what in the HTTPS world would be a Certificate Authority. For which you'll have the same kind of update/upgrade path questions that you very rightfully ask for the key lengths.

Very true. Early on in Java's gestation I was building into it a full capabilities system for security. One of the challenges of loading classes which provided export proscribed encryption capability was having the JVM authenticate the class, and having the class authenticate the JVM it was being loaded in to.

Of course not all situations need that, but understanding what the endpoints are trying to achieve and how that objective could be compromised by an attacker will inform on which identities must be established, and to whom, in order to achieve that objective.

Reply on news.ycombinator.com