21–30 of 64 posts
How is code like below "easily auditable"? keydir = *++argv; if (!keydir) die_usage(); or if (*x == 'v') { if (flagverbose >= 2) flagverbose = 3; else flagverbose = 2; continue; } why put multiple statements on the same line if you have nothing to hide?[1] [1] https://www.kernel.org/doc/Documentation/CodingStyle
Earlier quoted context omitted.
Yes, TweetNaCl is. TweetNaCl's goal is to be auditable, not to be portable. On the other hand, TinySSH actually includes a configuration mechanism to detect integer sizes, and modifies TweetNaCl accordingly, so TinySSH is not 32-bit/LLP64 only.
I wonder why not just use stdint.h, it's got what you need. ..
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. 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).
tar c path/to/files | ssh host tar x
$ wc -l source/*/*c | tail -n1
11308 total
$ wc -l source/crypto/*c | tail -n1
1293 total
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.
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.
[0] Daniel J Bernstein - author of qmail, daemontools and long-time promoter of full disclosure. https://en.wikipedia.org/wiki/Daniel_J._Bernstein
I find use of TweetNaCl curious. For curve25519, why wouldn't one use http://code.google.com/p/curve25519-donna/ instead? djb's cryptography is great, but djb's implementations leave something to be desired.
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…
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
*/
How is code like below "easily auditable"? keydir = *++argv; if (!keydir) die_usage(); or if (*x == 'v') { if (flagverbose >= 2) flagverbose = 3; else flagverbose = 2; continue; } why put multiple statements on the same line if you have nothing to hide?[1] [1] https://www.kernel.org/doc/Documentation/CodingStyle
Value consistency above everything.
Honestly, I am not convinced that the peculiar if-style isn't actually helping readability and refactoring. Note, that a Apple-style "goto break" bug might be harder to construct, when your one-line if's look like this:
some_code;
if (something) die(message);
other_code;
some_code;
if (something)
die(message);
other_code;
You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't.
On a side note: your second example even seems to suggest that the authors made some effort at additional readability by refraining from using the ternary operator construct.
How is code like below "easily auditable"? keydir = *++argv; if (!keydir) die_usage(); or if (*x == 'v') { if (flagverbose >= 2) flagverbose = 3; else flagverbose = 2; continue; } why put multiple statements on the same line if you have nothing to hide?[1] [1] https://www.kernel.org/doc/Documentation/CodingStyle
Because it's more readable.
Do
you
truly
find having
only a few
words per line
more
readable?
Does
it aid
with
comprehension?
I find having a high word density to be the most "readable", and it doesn't seem to matter whether it's C or English.
The TinySSH source code is small enough that I was able to read it in about 25 minutes and I learned about the SSH protocol along the way.
Earlier quoted context omitted.
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…
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_ch…
no older cryptographic primitives - rsa, dsa, classic diffie-hellman, md5, sha1, 3des, arcfour, ...
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. 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).