>You don't need to be running sshd. Given the relative complexities of the two daemons, it's vastly more likely that your server will be compromised via a vulnerability in sshd than via a vulnerability in spiped. (In fact, if you need to run SSH for the benefit of interactive logins, you're probably better off having sshd only listening on 127.0.0.1 and connecting to it via spiped.)
This is a really bad argument. It may be generally true that increased complexity leads to more vulnerabilities in general, but it's not necessary that increased size leads to a large increase in complexity. Poor software design that involves a lot of strange relationships between components inside of an application leads to vulnerabilities. Unless your code base is so small you can provide formal proofs of security, you can make absolutely no assertions based on code size that your code is more or less vulnerably than larger code bases.
Additionally, the number of attempts to break OpenSSH because of the massive user-base gives it a stronger security foundation than you to imply. Put another way, there are massive economic incentives for hackers to pour hours into finding vulnerabilities in OpenSSH since it's the gateway to millions of *nix systems on the Internet. Has spiped been subject to that level of scrutiny?
As a security-minded person, you should not be making grandiose claims about freshly released software being so much more secure than OpenSSH that it should be used to protect OpenSSH endpoints. Would you trust a newly released symmetric crypto algorithm more than AES just because it performed fewer operations?
I agree with Colin. I feel much safer with spiped than I would with OpenSSH, even though my opinion of OpenSSH is reasonably high (I trust it more than nginx, for instance). I'm familiar with both codebases, and spiped is just a lot simpler than OpenSSH.
Have you performed a full security audit of the spiped code? If not, the only way you can sanely make that argument is via an appeal to authority, which is probably acceptable given tarsnap's reputation. Is that what you're doing here?
First, an "appeal to authority" is fallacious when the authority isn't relevant. In a discussion of cryptosystems, an appeal to Colin Percival's authority is a valid argument! It's obviously not dispositive, but it's not something you can simply dismiss; you'd need to rebut it with countervailing arguments. Technically, the authority I appealed to in my comment was my own. I happen to think that's also a valid argument, albeit one requiring fewer countervailing arguments. :)
The term "appeal to authority" is misused about as often as "ad hominem".
Second, if you reread my comment more carefully, you'll see that it pre-rebuts the argument you've made here.
I am absolutely prepared to have a debate about the relative safety of spiped and OpenSSH. Please, feel free to marshall some arguments in favor of OpenSSH. A comparative code review of the two projects sounds like a pleasant way to spend a lazy Sunday.
>First, an "appeal to authority" is fallacious when the authority isn't relevant. In a discussion of cryptosystems, an appeal to Colin Percival's authority is a valid argument! It's obviously not dispositive, but it's not something you can simply dismiss; you'd need to rebut it with countervailing arguments. Technically, the authority I appealed to in my comment was my own. I happen to think that's also a valid argument, albeit one requiring fewer countervailing arguments. :)
If you read my comment, you would see that I said it was probably valid in this case due to tarsnap's reputation. I was just clarifying the argument you were making to see if you actually had already performed a code review of spiped. However, an appeal to authority is still not valid (in academia at least), it's just a useful tool to shortcut arguments. When it gets down to the nitty-gritty of talking about showing that something is secure, if something is not dispositive, you can and you must dismiss it without regard.
>I am absolutely prepared to have a debate about the relative safety of spiped and OpenSSH. Please, feel free to marshall some arguments in favor of OpenSSH. A comparative code review of the two projects sounds like a pleasant way to spend a lazy Sunday.
Reread my comment in response to his, you should understand that the burden of proof lies with anyone claiming product X is more secure than OpenSSH. You cannot come in and claim spiped is simply more secure than OpenSSH on an argument of code-size alone. The security community is better than that.
Also, I already gave an argument in favor of OpenSSH in its current state from the economic perspective. There is a nearly limitless treasure chest of computing power and bandwidth available to people who discover vulnerabilities in OpenSSH. In that regard, it's received orders of magnitude more scrutiny than spiped. From the academic side, OpenSSH is a popular target for experiments in static and dynamic analysis because a new automated method that discovers a vulnerability in something like OpenSSH will guarantee citations and top venue.
On a related note, vulnerabilities so egregious that require you to shield OpenSSH using spiped implies that OpenSSH is fundamentally broken. If that's the case, what's the expected method of installing spiped and the symmetric keys on something like an EC2 instance?