Hacker News Reader

Comment by elromulous | Hacker News Reader

I love the concept, specifically launching new servers to avoid dynamic allocation. However: > no dependency on OpenSSL - TinySSH has its own crypto library compatible with NaCl, Libsodium

Apologies in advance for being a security curmudgeon, but I'll eat my hat if their homegrown crypto library doesn't have vulnerabilities. Crypto is hard, even for the best experts. The only way to get this right is with code that's had many eyes on it and has been battle tested.

View on HN

NaCl/libsodium is a modern implementation by crypto experts. It's as far cry from "homegrown" as you can get. Arguably, it's better designed than OpenSSL, having been started by crypto experts in response to Heartbleed and the concern for the code quality and legacy code in OpenSSL.

Edit: my bad, TinySSH is using its home-grown version of NaCl, so parent's comment applies.

They're not using NaCl, they're using a custom code implementation of the relevant NaCl interfaces.

Yeah, but it's not using NaCl or libsodium. It just says it's "compatible with" them.

> speed - TinySSH can be also compiled using high-speed NaCl library instead of internal.

Sounds like you can use NaCI directly.

I wonder what is the advantage of one over the other? The faq doesn't say.

Probably just the fact they can build completely "in house" with no dependencies. A lot like the appeal of static binaries (with plentiful drawbacks ofc)

A small, 0-alloc, statically linked SSH server is perfect for installation on consumer routers that manufacturer didn't intend to run SSH

Sure, but OP wasn't pointing out they use NaCl/libsodium.

> TinySSH has its _own_ crypto library _compatible_ with NaCl, Libsodium...

Compare with:

TinySSH has its _own_ crypto library _compatible_ with NaCl: Libsodium

> having been started by crypto experts in response to Heartbleed

This isn't quite right. NaCl is a Daniel J. Bernstein project that predates Heartbleed by several years[0]. Though I'm sure Heartbleed generated new interest in better designed, more secure, crypto libraries.

[0] https://en.wikipedia.org/wiki/NaCl_(software)

> Edit: my bad, TinySSH is using its home-grown version of NaCl, so parent's comment applies.

Looks like tweetnacl split back up into the same files as the reference implementation.

If I understand correctly, what this reply is suggesting is that the tinyssh author took reference implementions for certain primitives from djb and changed them into something "home-grown" that is consequently now vulnerable because [unspecified]. That's quite a bold claim. To be fair, when compiling tinyssh the build script checks for external versions of these primitives before using the supplied "home-grown" ones.

There is an obvious error in this reply as well. NaCl was not "started by crypto experts in response to Heartbleed." NaCl was published in 2011 and the Heartbleed did not occur until 2014.

Annoyingly, NaCl is a crypto library by Daniel Bernstein and NaCl is a sandboxing solution by Google.

I use tinyssh. Have used it since 2014 without any problems. I use the external NaCl library, not the internal one based on TweetNaCl.

If NaCl, or even TweetNaCl, is "homegrown crypto" why are all these projects using it: https://ianix.com/pub/curve25519-deployment.html OpenSSH included.

How much does tinyssh's internal library differ from TweetNaCl's? Wouldn't a security curmudgeon at least examine those differences. If the user downloads NaCl from https://nacl.cr.yp.to first, tinyssh will use the external NaCl library not the "homegrown" internal library based on TweetNaCl. I never use the internal library.

If it's compatible, what's supposed to be the value in re-implementing libsodium instead of just vendoring or forking it and copying in the important parts?

Reply on news.ycombinator.com