3 ms·

I've been working on a secure UDP file transfer protocol recently and this was of particular interest to me because I ended up using many of the same design cho

I've been working on a secure UDP file transfer protocol recently and this was of particular interest to me because I ended up using many of the same design choices. At the same time, my implementation ends up being simpler since I limit the types of digests and ciphers used. It really goes to show you how difficult it is to create a general protocol that allows for massive flexibility while keeping it secure.

lvh 10y ago
Out of interest, how do you verify the similar design choices? For example, how do you check that, say, your AKE is KCI-secure?
- alfalfasprout 10y ago
  By keeping it simple and sticking with proven building blocks and patterns so as to not "roll my own crypto" (which is very, very bad). If you're using something like AES in GCM mode and ECDHE the only part where you have some leeway in implementation is in how you exchange the ephemeral keys. I largely get around this because both clients and servers are required to have valid X509 certificates and the protocol won't proceed if they can't mutually authenticate. You can use these certificates to sign the preliminary messages (selecting ciphers, digests, and protocol specific parameters) until the key exchange is complete and you're encrypting everything with the ephemeral keys. At that point, even if the static keys are compromised you still get PFS. You can also mitigate things like KCI MITM attacks by simply forcing strong cipher suites and key derivation protocols. AES-128-GCM and AES-256-GCM when used with ephemeral ECDH (using the right curves) is very well studied and known to provide PFS among other things.
  - lvh 10y ago
    AES-GCM with ephemeral ECDH and the right curves don't imply KCI MITM protection, though. What does your application do?
    - tptacek 10y ago
      A crisper way to put this would be to point out that GCM has virtually nothing to do with KCI, since KCI is a key agreement vulnerability.
lvh 10y ago
Noise is a blueprint for a lot of concrete protocols, mostly in the way that TLS has many ciphersuites. While most TLS implementations need to speak most ciphersuites in order to be useful, Noise applications are typically bespoke, so applications using Noise will typically also limit themselves to one ciphersuite and one Noise mode, e.g. Noise_IK_448_ChaChaPoly_BLAKE2b.
- alfalfasprout 10y ago
  I'm excited see things like this because there are a lot of applications now starting to use homebrew crypto protocols and not all of them follow good design practices to mitigate even common pitfalls in something like a key exchange (despite using vetted libraries for crypto primitives). Having good, vetted patterns like Noise that cover key exchange and authentication should help improve the security of a lot of these applications.

lvh 10y ago

Out of interest, how do you verify the similar design choices? For example, how do you check that, say, your AKE is KCI-secure?

alfalfasprout 10y ago
By keeping it simple and sticking with proven building blocks and patterns so as to not "roll my own crypto" (which is very, very bad). If you're using something like AES in GCM mode and ECDHE the only part where you have some leeway in implementation is in how you exchange the ephemeral keys. I largely get around this because both clients and servers are required to have valid X509 certificates and the protocol won't proceed if they can't mutually authenticate. You can use these certificates to sign the preliminary messages (selecting ciphers, digests, and protocol specific parameters) until the key exchange is complete and you're encrypting everything with the ephemeral keys. At that point, even if the static keys are compromised you still get PFS. You can also mitigate things like KCI MITM attacks by simply forcing strong cipher suites and key derivation protocols. AES-128-GCM and AES-256-GCM when used with ephemeral ECDH (using the right curves) is very well studied and known to provide PFS among other things.
- lvh 10y ago
  AES-GCM with ephemeral ECDH and the right curves don't imply KCI MITM protection, though. What does your application do?
  - tptacek 10y ago
    A crisper way to put this would be to point out that GCM has virtually nothing to do with KCI, since KCI is a key agreement vulnerability.

lvh 10y ago

Noise is a blueprint for a lot of concrete protocols, mostly in the way that TLS has many ciphersuites. While most TLS implementations need to speak most ciphersuites in order to be useful, Noise applications are typically bespoke, so applications using Noise will typically also limit themselves to one ciphersuite and one Noise mode, e.g. Noise_IK_448_ChaChaPoly_BLAKE2b.

alfalfasprout 10y ago
I'm excited see things like this because there are a lot of applications now starting to use homebrew crypto protocols and not all of them follow good design practices to mitigate even common pitfalls in something like a key exchange (despite using vetted libraries for crypto primitives). Having good, vetted patterns like Noise that cover key exchange and authentication should help improve the security of a lot of these applications.