Re:Libsodium 1.0.0 released
by tptacek on Wednesday September 24, 2014 @02:56PM
(#8363391)
It's better if you don't build crypto directly into your application at all, because you can still screw things up even if you build on Nacl. But with that said: Sodium/Nacl is better than virtually any of your other options for working directly with cryptography.
[ Parent
| on HN ]
> It's better if you don't build crypto directly into your application at all, because you can still screw things up even if you build on Nacl.
Nacl was built to provide an API that is incredibly hard to screw up. That was one of djbs primary motivations. If you just need asymmetric encryption, or signing, or hashing, then it's the bees knees. These broad concepts aren't difficult to comprehend, and every developer should strive to understand and be able to use them. We shouldn't be encouraging people to be afraid... especially when things like dumb, plaintext username and password authentication is routinely implemented by developers without a second thought already.
Nacl makes it hard to screw up the constructions. It doesn't make it hard to make invalid assumptions about what a signed encrypted blob actually means.
+ makes it easy to add two numbers. It doesn't make it hard to make invalid assumptions about what adding two numbers together actually means.
Nacl is a good thing. But crypto is just a tool. It's not a magic wand. People have already built vulnerable systems by making bogus assumptions about what Nacl can do.
Re:Libsodium 1.0.0 released
by sarciszewski on Sunday September 28, 2014 @01:00AM
(#8378974)
That's a shame :(
Can you recommend how to wrap crypto _around_ our applications if we aren't building it in?
Re:Libsodium 1.0.0 released
by sarciszewski on Wednesday September 24, 2014 @03:49PM
(#8363695)
"It's better if you don't build crypto directly into your application at all"
Plaintext all of the things! :P
I'm curious to know what you'd recommend for people who are looking to build applications around novel network protocols that aren't interested in the the certificate authority aspect of TLS?
There's no reason you have to use CAs to authenticate TLS. Plenty of enterprise tools keep whitelists of certificate hashes instead.
There's an RFC on TLS with raw public keys that you should probably check out: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-02.
There are several TLS modes that don't use certificates. SRP and PSK are the two that I have some limited experience with. Both require sharing a password or key beforehand through some other medium.
If you're not concerned with man-in-the-middle attacks, then you could also use the ANON modes.
Re:Libsodium 1.0.0 released
by revelation on Thursday September 25, 2014 @08:33AM
(#8366782)
If you control the client software, theres no reason to use a certificate authority instead of making your own CA or just using self-signed certificates.
Re:Libsodium 1.0.0 released
by higherpurpose on Wednesday September 24, 2014 @07:34PM
(#8364741)
This maybe: