11–20 of 20 posts
What advantage does this have over spiped[1]? Since there's not really a good way to distribute public keys, you really need to just put them on a thumb drive and walk them over to the person that wants them. And if you're doing that, you might as well give the person a shared secret. [1]: https://www.tarsnap.com/spiped.html
What advantage does this have over spiped[1]? Since there's not really a good way to distribute public keys, you really need to just put them on a thumb drive and walk them over to the person that wants them. And if you're doing that, you might as well give the person a shared secret. [1]: https://www.tarsnap.com/spiped.html
See the following presentation, which presents insecure key exchange protocols (the key exchange from the article is on page 4) while building up to SIGMA: https://www.ietf.org/proceedings/52/slides/ipsec-9.pdf
As you can see, this stuff is hard and you really shouldn't be designing your own. CurveZMQ (basically, DJB's CurveCP over TCP) is probably a better choice if you want a NaCl-based secure channel. CurveZMQ also happens to be pretty well documented if you want to learn about what it takes to design a secure protocol: http://curvezmq.org/page:read-the-docs
Interesting. A couple of questions that come to mind: - Any rough benchmarks vs. TLS? Or even just back-of-the-envelope math/reasoning behind the claim in the opening paragraph: "without the overhead of TLS". - Instead of generating 24 PRNG bytes for each message to use as the NaCl nonce, why not use the sequence number each message is assigned anyway?
nacl says that for security each nonce/key pair must be unique for each message. If you send a "HELO" message, for example first, you've made it possible to build a pretty simple rainbow table if nonce just starts at 0 or 1. That said, it would seem that the first nonce being random and then incremented would likely work well.
What advantage does this have over spiped[1]? Since there's not really a good way to distribute public keys, you really need to just put them on a thumb drive and walk them over to the person that wants them. And if you're doing that, you might as well give the person a shared secret. [1]: https://www.tarsnap.com/spiped.html
Interesting. A couple of questions that come to mind: - Any rough benchmarks vs. TLS? Or even just back-of-the-envelope math/reasoning behind the claim in the opening paragraph: "without the overhead of TLS". - Instead of generating 24 PRNG bytes for each message to use as the NaCl nonce, why not use the sequence number each message is assigned anyway?
nacl says that for security each nonce/key pair must be unique for each message. If you send a "HELO" message, for example first, you've made it possible to build a pretty simple rainbow table if nonce just starts at 0 or 1. That said, it would seem that the first nonce being random and then incremented would likely work well.
"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." - Adam Langley, Google.
[1] http://www.zdnet.com/article/openbsd-forks-prunes-fixes-open...
You wouldn't want to use this. The key exchange is vulnerable to replay and identity misbinding attacks. To fix the replay attack, you also need to sign a nonce from the peer (or its ephemeral public key) to prove that the message is fresh. To fix the identity misbinding attack, you also need to sign the identity of the peer. Then it's probably secure, but the protocol would lack identity hiding. You really want a ke…
You wouldn't want to use this. The key exchange is vulnerable to replay and identity misbinding attacks. To fix the replay attack, you also need to sign a nonce from the peer (or its ephemeral public key) to prove that the message is fresh. To fix the identity misbinding attack, you also need to sign the identity of the peer. Then it's probably secure, but the protocol would lack identity hiding. You really want a ke…
Didn't CodesInChaos document a misbinding attack against CurveCP, too?
[1] https://codesinchaos.wordpress.com/2012/09/09/curvecp-1/