

Ask HN: Encrypted UDP? - pjungwir

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&#x27;t want to block on network activity--you just want to fire off the message and keep going--but you <i>do</i> 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&#x27;ve seen DTLS, which is close, but has poor support on Windows and in scripting languages. Is there anything else out there? Thanks HN!
======
Bino
DTLS 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
Thanks 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
Variations on [https://en.wikipedia.org/wiki/Secure_Real-
time_Transport_Pro...](https://en.wikipedia.org/wiki/Secure_Real-
time_Transport_Protocol) \- 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
"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.

------
conductor
DTLS -
[https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...](https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security)

------
kogir
Just use IPsec, and then use UDP normally.

~~~
Bino
"IPsec" doesn't always protect you against replay attacks for encapsulated UDP
packets (unlike TCP which protects itself).

~~~
kogir
I 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
Yes, 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....](http://www.ietf.org/mail-
archive/web/ipsec/current/msg05871.html)

