Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some gripes about nacl

tedunangst.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Some gripes about nacl

#31

Post by bascule »

nightcracker wrote: post #29
metafex wrote: post #5

Simply put, use the reference nacl implementation only when you really know what you're doing. As with all things crypto it's easy to shoot yourself in the foot, and libsodium makes it a bit harder than reference nacl.

If you really know what you are doing you aren't even using NaCl, you use the individual algorithms. For example: https://github.com/orlp/ed25519 .

If you really know what you're doing, you'd use a fast assembly implementation that's guaranteed to run in constant time, like curve25519/ed25519-donna, both of which you get for free if you just use libsodium.

Re: Some gripes about nacl

#32

Post by zackmorris »

wise0wl wrote: post #27
amenonsen wrote: post #21

As someone who didn't really know what they were doing, I used NaCl recently to write a program to tunnel packets over UDP. I started by reading the NaCl source and all the introductory material available—the web site, the two NaCl papers ("Cryptography in NaCl", "The security impact of a new cryptography library"), and quickly reviewed a couple of other papers (e.g. to understand deterministic encryption and D-H key…

A former colleague wrote a tool for just such a thing (Encrypted UDP tunneling) http://nardcore.org/ctunnel/

This looks good, but from a brief glance I can't seem to find if/how it implements windowing in net.c. I'm guessing it just waits for an ACK before continuing? I'm searching for something very much like this, where I could bind to a TCP socket that uses UDP internally, something like ZeroMQ, for punching through NAT with STUN or something similar.

Re: Some gripes about nacl

#33

Post by X-Istence »

geofft wrote: post #25
minthd wrote: post #15

Isn't the fact that nacl is written by such highly reputable guy(in the crypto community) and that it sees relatively lots of review by experts important here ?

He's a highly reputable cryptographer, and a ... controversial ... software developer. I would trust my life to the algorithms. I wouldn't trust my appendix to the code. The software is delivered over HTTP (not HTTPS) and not cryptographically signed. I've always interpreted this as a statement that, if you're not qualified to review what you just downloaded and make sure it's not malicious and that it faithfully imp…

For years I ran vanilla qmail with two patches (AUTH support for sending authentication, and a patch to allow for a database of valid supported emails so you get rid of the backscatter issue).

It was absolutely fantastic, it ran without issues for years. It was very fast and I never had issues with losing mail or behaviours that baffled me or left me scratching my head.

I currently have a postfix setup, and while it works well I am very wary of upgrading it for fear of breaking something and causing mail to bounce or not be delivered. With qmail it would just queue mail if you accidentally misconfigure something (such as the delivery program is unavailable), with Postfix I've had it simply drop mail on the floor. Sure they are issues that could be solved with better testing, and verification of systems, but qmail is a lot more forgiving without bouncing.

Re: Some gripes about nacl

#34

Post by _paulc »

The easiest way to get round the slightly odd build environment for NaCl is to just use TweetNaCl (http://tweetnacl.cr.yp.to/software.html) which just requires you to drop a single .c/.h file into your project - this isn't as performant as the reference code but in most cases this probably doesn't matter. The libsodium implementation seems overly complicated to me for most uses.

The NaCl API is reasonably simple and is fairly easy to wrap (plug - if anyone is looking for an example have a look at jim-nacl [1] which embeds into Jim TCL)

[1] https://github.com/paulchakravarti/jim-nacl

Re: Some gripes about nacl

#35

Post by stormbrew »

X-Istence wrote: post #33
geofft wrote: post #25

Earlier quoted context omitted.

He's a highly reputable cryptographer, and a ... controversial ... software developer. I would trust my life to the algorithms. I wouldn't trust my appendix to the code. The software is delivered over HTTP (not HTTPS) and not cryptographically signed. I've always interpreted this as a statement that, if you're not qualified to review what you just downloaded and make sure it's not malicious and that it faithfully imp…

For years I ran vanilla qmail with two patches (AUTH support for sending authentication, and a patch to allow for a database of valid supported emails so you get rid of the backscatter issue). It was absolutely fantastic, it ran without issues for years. It was very fast and I never had issues with losing mail or behaviours that baffled me or left me scratching my head. I currently have a postfix setup, and while it…

I also quite prefer qmail to postfix in terms of its flexibility and resilience, but it really does highlight one of the biggest problems with long term use of djb software: It always seems to reach a point where djb feels it's done (or he's done with it) and it sits there for years with no updates, while still appearing to be the authoritative version of that product.

Vanilla qmail is genuinely unusable on the internet today (because of the backscatter issue in particular), but netqmail, which is still maintained, still looks like a secondary fork to someone who doesn't know the history. It doesn't help that djb for a long time used licensing that was incompatible with reasonable distribution of these forks as well.

So these days I actually tend to go for the forks and clones of djb software where possible. I use netqmail on my mail server, runit instead of daemontools, etc.

Re: Some gripes about nacl

#36

Post by urras »

_paulc wrote: post #34

The easiest way to get round the slightly odd build environment for NaCl is to just use TweetNaCl ( http://tweetnacl.cr.yp.to/software.html ) which just requires you to drop a single .c/.h file into your project - this isn't as performant as the reference code but in most cases this probably doesn't matter. The libsodium implementation seems overly complicated to me for most uses. The NaCl API is reasonably simple an…

Might also want to checkout libsodium (https://github.com/jedisct1/libsodium).

Re: Some gripes about nacl

#37

Post by api »

Good API design is, like "installability," a critical and often neglected aspect of software engineering. I find that bad APIs are the norm in every area, not just crypto. Audio and video stuff is just hideous.

I used the NaCl crypto for ZeroTier One but basically refactored the code into C++ classes that build like normal modern C++.

Re: Some gripes about nacl

#39

Post by geofft »

23david wrote: post #30

Is nacl deprecated in favor of the libsodium fork ? Or are both projects strong and continuing in parallel? [libsodium] is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further. Source: https://github.com/jedisct1/libsodium/blob/master/README.mar... I see DJB (original nacl creator http://nacl.cr.yp.to/ ) appears to contribute…

Being listed in the AUTHORS file does not imply active participation. libsodium is based on NaCl's algorithms and code, both of which are publicly reusable, but I think they were placed in libsodium by other people. If you clone the repo, `git log --author=bernstein` and `git log --author=djb` return no results.

It's probably worth treating NaCl as something like research code or a reference implementation. It's certainly way more usable than most research code is, which is extremely commendable, but it's still not quite libsodium in terms of its goal as a product.

Re: Some gripes about nacl

#40

Post by 23david »

geofft wrote: post #39
23david wrote: post #30

Is nacl deprecated in favor of the libsodium fork ? Or are both projects strong and continuing in parallel? [libsodium] is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further. Source: https://github.com/jedisct1/libsodium/blob/master/README.mar... I see DJB (original nacl creator http://nacl.cr.yp.to/ ) appears to contribute…

Being listed in the AUTHORS file does not imply active participation. libsodium is based on NaCl's algorithms and code, both of which are publicly reusable, but I think they were placed in libsodium by other people. If you clone the repo, `git log --author=bernstein` and `git log --author=djb` return no results. It's probably worth treating NaCl as something like research code or a reference implementation. It's cert…

I noticed that and assumed that DJB may just not be a 'social coder' with a github account :-)
Post reply on HN