Outstanding! Not only are the slightly mysterious authors of this project
not inventing their own crypto, they rely on djb's[0] much acclaimed
NaCL/TweetNaCl. The codebase is accordingly small:<p><pre><code> $ wc -l source/*/*c | tail -n1
11308 total
$ wc -l source/crypto/*c | tail -n1
1293 total
</code></pre>
The first line suggests a measure of total code ballast, whereas the
second incantation might hint at the amount of core crypto code. The latter
might be a good starting point for any auditing endeavours.<p>Incidentally, I am impressed by the spirit of organisation that the source
tree permeates. Both crypto/ and tinyssh/ source trees sport corresponding
-test directories and a debian/ tree has already been added.<p>Initially, I felt irritation by the consistent lack of documentation (no
README, no AUTHORS, almost no comments, it seems). Browsing the source,
however, I grow convinced that this from a conviction that out-dated or
redundant documentation is the greater evil.<p>[0] Daniel J Bernstein - author of qmail, daemontools and long-time promoter
of full disclosure. <a href="https://en.wikipedia.org/wiki/Daniel_J._Bernstein" rel="nofollow">https://en.wikipedia.org/wiki/Daniel_J._Bernstein</a>
How is code like below "easily auditable"?<p><pre><code> keydir = *++argv; if (!keydir) die_usage();
</code></pre>
or<p><pre><code> if (*x == 'v') { if (flagverbose >= 2) flagverbose = 3; else flagverbose = 2; continue; }
</code></pre>
why put multiple statements on the same line if you have nothing to hide?[1]<p>[1] <a href="https://www.kernel.org/doc/Documentation/CodingStyle" rel="nofollow">https://www.kernel.org/doc/Documentation/CodingStyle</a>
Curious as to whether something like this would be good for embedded work, as I'm working on a "modern" HP 200LX[0] running RetroBSD[1] possibly, all off a PIC micro controller (!) and want to work out how to get some form of SSH into it. Will be interesting to attempt to port it regardless of what happens though!<p>----<p>[0] <a href="http://en.wikipedia.org/wiki/HP_200LX" rel="nofollow">http://en.wikipedia.org/wiki/HP_200LX</a><p>[1] <a href="http://retrobsd.org/wiki/doku.php" rel="nofollow">http://retrobsd.org/wiki/doku.php</a>
Someone know how it compares with dropbear [1]?<p>1. <a href="https://matt.ucc.asn.au/dropbear/dropbear.html" rel="nofollow">https://matt.ucc.asn.au/dropbear/dropbear.html</a>
Awesome! A few questions/thoughts:<p>Right now, you're suggesting it be downloaded via HTTP, which isn't exactly the best way to get my secure daemons. Any chance you could move that to HTTPS?<p>Semi-related: any chance you'll be making a repo available in some form? (I'm preferential to GitHub, but really anything that lets us follow source changes and open bug reports would rock)<p>I would love to see an audit of this by some 3rd party entity.<p>Glad to see folks working to build new tools from such solid building blocks!
I find use of TweetNaCl curious. For curve25519, why wouldn't one use <a href="http://code.google.com/p/curve25519-donna/" rel="nofollow">http://code.google.com/p/curve25519-donna/</a> instead?<p>djb's <i>cryptography</i> is great, but djb's <i>implementations</i> leave something to be desired.
Is TweetNaCl deliberately 32-bit or LLP64 only? One of the first lines is<p><pre><code> typedef unsigned long u32;
</code></pre>
but on 64-bit LP64 systems (like Linux), <i>long</i> is 64-bits.<p>See <a href="http://tweetnacl.cr.yp.to/20140427/tweetnacl.c" rel="nofollow">http://tweetnacl.cr.yp.to/20140427/tweetnacl.c</a>
What use is an sshd that doesn't support SCP? I think to most people that is a core feature, I'd be surprised if it wasn't a requirement for git for example.<p>It sounds like it's small enough perhaps for a direct port to a safe language like rust, that would be interesting (to me at least).
Rob Landley doesn't seems to be too excited about it
<a href="http://www.landley.net/notes.html#31-03-2014" rel="nofollow">http://www.landley.net/notes.html#31-03-2014</a>
Every function name in tinyssh/buf.c starts with an underscore...<p>To quote the standard:<p>"All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
...
If the program declares or defines an identifier in a
context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined."<p>-- ISO/IEC 9899:1999, Section 7.1.3 Reserved Identifiers