end-to-end encryption

[johannestaas]

An attacker who can MITM the connection can obtain password hashes that they can crack offline, or replay the traffic for undesirable consequences (separate issue).

Might be possible to use this: https://pypi.python.org/pypi/Dtls/0.1.0

Some sort of real authentication with secrecy and integrity checking would be better.

[0xPoly]

Is there a way to implement DTLS for broadcast? Because my understanding is that TLS over UDP requires a handshake with each host, which can be tedious to do if you are connecting to a large number of nodes.

[johannestaas]

Ouch... Not sure. Bottom line though, you don't want people reading what you send, you shouldn't need to send it plaintext, and you step into a very dangerous realm once you start working with crypto primitives on your own, like an AES cipher, hash, etc. Crypto is extremely hard to get right, and professionals will generally suggest that you either use openSSL or GPG and not touch lower level implementations.

Okay, one attribute of your tool is that you don't want to have to do a handshake. Not only is it not convenient, but it's probably less secure. What if an attacker sees the incoming connection and breaks the handshake? You should be able to send one UDP bullet and kill the device immediately. Unless something exists that will be able to do this for you, you're somewhat forced to roll your own crypto. It won't be hard to make it run, just extremely hard to make it so that it can't be messed with.

You will need secrecy, integrity checking, and authentication. One possible route is AES256 with an HMAC. That might look like this:

IV = 8 bytes from /dev/urandom PANIC_CYPHERTEXT = AES256(aes_key, PKCS5("mysecretpanicphrase"), mode=CBC, iv=IV) UDP_PAYLOAD = HMAC(IV + PANIC_CYPHERTEXT, hmac_key)

All lowercase supplied by user.

Now, how do we make this immune to replay attacks?

Here's one way, that will work 5 times. Take an original aes_key, and hash it, to get hash(key). Now hash that to get hash(hash(key)) What happens is the service will expect the first time to get hash(hash(hash(key))). Once it gets that, it subtracts one layer. Now the program expects just hash(hash(key)), all the way until hash(key), which is when the key expires.

The key changes, but it's based on one key you supply, and once you triggered it to a device, they can only replay it to devices that haven't seen the first one, which may be actually desirable in this case. Seeing it to one will effectively broadcast it to the rest if the attacker replays it, but they can't continuously replay it to DoS the devices, unless they figured out the original key, and even then they could only do it x number of times.

NOW... the best thing is still to find a reputable module that has already implemented a way to do all this via UDP for you, something that is maintained by someone who knows how to code secure crypto. If not, you might be stuck doing it yourself and then submitting the scheme to /r/crypto to ask for advice, but expect to hear a lot of "don't roll your own crypto". In fact, it's best to submit your scheme there before prototyping it because they might find a major flaw.

But first, try to find a suitable module made by a reputable crypto dev. I'm just a hobbyist.

Cheers, Johan

On Tue, May 27, 2014 at 1:37 PM, Poly notifications@github.com wrote:

Is there a way to implement DTLS for broadcast? Because my understanding is that TLS over UDP requires a handshake with each host, which can be tedious to do if you are connecting to a large number of nodes.

— Reply to this email directly or view it on GitHubhttps://github.com/0xPoly/Centry/issues/5#issuecomment-44331940 .