4 ms·
Ask HN: Encrypted UDP?
Is there any way to use UDP for private, authenticated messages? Suppose your use case is like statsd, where you can tolerate the occasional lost message, and you don't want to block on network activity--you just want to fire off the message and keep going--but you do want your messages encrypted, and you want to make sure the receiver can trust the message is from you. Someone else should not be able to replay your message and have the receiver accept it. An attacker should not be able to break the encryption after sniffing n messages. Is there any existing protocol that provides such a blend of features? I've seen DTLS, which is close, but has poor support on Windows and in scripting languages. Is there anything else out there? Thanks HN!
- conductor 13y agoDTLS - https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...
- kogir 13y agoJust use IPsec, and then use UDP normally.
- Bino 13y ago"IPsec" doesn't always protect you against replay attacks for encapsulated UDP packets (unlike TCP which protects itself).
- kogir 13y agoI thought that was the point of the Authentication Header Sequence Number and the sliding window? If you can tolerate occasional lost packets you can require they only increase and achieve complete protection, no?
- Bino 13y agoYes, you're absolutely right about the existence of Seq. Numbers in IPsec. However, it might not always be enabled, that is if you're using manual keying (and not IKE). http://www.ietf.org/mail-archive/web/ipsec/current/msg05871.html http://www.ietf.org/mail-archive/web/ipsec/current/msg05871....
- Bino 13y agoDTLS is probably one of your best options. Protecting UDP is hard. It more or less requires you to implement "all" the features DTLS has (like sequence numbers). Depending on the application, one could argue that your protocol maybe shouldn't implements encryption (wouldn't be the first protocol not to do so). And it should be left to the user to protect the traffic in their network. In some sense it's better not to try (and be open about it) than to fail.
- pjungwir 13y agoThanks for your opinion! I sort of agree. I'm trying to understand the DTLS RFC, and it sounds like DTLS (and maybe anything else that avoids replay attacks) requires you to set up a "conversation" initially, which sort of reduces the appeal of UDP. So lifting that work out of the protocol into an outside context, which the user could set up or not, might be best.
- ahazred8ta 13y agoVariations on https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol https://en.wikipedia.org/wiki/Secure_Real-time_Transport_Pro... - mainly used as ZRTP, or DTLS+SRTP, or SRTP with manual key setup. Related: port knocking utils use encrypted/authenticated UDP datagrams; there are secure chat / instant messenger libraries using UDP; VoIP uses secure UDP. a minimalist approach is http://www.the-control-freak.com/ClntSrvr/AES/AES.htm http://www.the-control-freak.com/ClntSrvr/AES/AES.htm
- ahazred8ta 13y ago"poor support on Windows and in scripting languages" Try the libsodium / NaCl / pynacl family of crypto libraries, which handle UDP, work on Windows, OS X and *nix, and plug into any scripted language that can talk to a C api.