The usual problem with DJB's implementations is not that they're incorrect or slow or insecure -- far from it! -- but that they're awkward to integrate with the rest of the world, may require weird build configurations, and are hard for anybody else to modify. Well, TweetNaCl is really easy to integrate with the rest of the world, since it's just a single portable .c file, and the speed is surprisingly good, and its functionality and API are stable enough that you probably don't need to modify it.

So, I don't see the problem here. If these guys had tried to cobble together a replacement for NaCl out of pieces like the curve25519-donna code, that would be a problem, because there's more potential to screw that up.

I see 3 alternatives: use the original NaCl, use the unofficial fork libsodium, or use TweetNaCl. The latter shares the same authors as the original NaCl, with the advantage of being much smaller.

I don't like the fact that TinySSH modified TweetNaCl, and added back MD5:

  /*
  Based on tweetnacl 20140427 (http://tweetnacl.cr.yp.to   software.html)
  - updated int/uint types to crypto_int/crypto_uint
  - added crypto_stream_chacha20
  - added crypto_hash_sha256
  - added crypto_hash_md5
  */

I mean they use TweetNaCl because it has "state-of-the-art crypto", but then they add back MD5. Something is wrong here ...

Not sure why they added that back but the website states that

  no older cryptographic primitives - rsa, dsa, classic diffie-hellman, md5, sha1, 3des, arcfour, ...

It is actually used in the code though. I didn't look into for what it was used though.

That seems strange indeed. Some clarification is needed. Perhaps it's part of the whole NIST suite that's disabled right now?

It appears to be used only in tinysshd-printkey to print the key's fingerprint.

The fingerprint is 47 characters when printed, the key itself is 64. Since the key is so short does the fingerprint still server a useful purpose, or would it be enough to print only the key?

What do they leave to be desired? Style is a personal preference, of course - but merit? Every single djb implementation I've seen (a lot of them) is fast, efficient, secure, and clear, once you get his style.

Mostly his disregard for packaging conventions and unwillingness to acomodate them. The code is usually A grade, but the odd use of the filesystem, runtime configs, daemons etc. means it will never get into any mainstream distro without heavy patching.

There's a reason why libsodium's tag line is "P(ortable|ackageable) NaCl-based crypto library".

The word of distros/packagers isn't gospel, but it counts for a lot, considering that (for better or worse) most people won't even think about using something not available as a package.

I've been doing "apt-get install daemontools daemontools-run" since forever on Ubuntu; it might take a little longer to get into the repositories, but it does get into mainstream distros with almost no patching -- comparable, IIRC, to packages of similar size and complexity that do not have an upstream debian packaging.