[hueving]

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?

[tptacek]

Ok, two things.

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.

[hueving]

>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?

[tptacek]

You're right: there is more incentive to find OpenSSH vulnerabilities than spiped vulnerabilities, and so the absence of OpenSSH vulnerabilities is more telling than the absence of spiped vulnerabilities.

But spiped is so much simpler than OpenSSH that more is going on: it's not merely that fewer people are looking, but that there is less to find.

Look over the history of OpenSSH vulnerabilities and reduce them to the subset that could possibly have affected spiped and you'll see what I mean. spiped benefits from having less mechanism than OpenSSH.

The idea behind deploying spiped is that you leave OpenSSH exposed for the tiny window of time required to get spiped deployed, and then you turn it off. Even if OpenSSH is totally broken, you still benefit from the fact that attackers aren't omniscient. A similar, weaker property is the reason every host running nginx hasn't been owned up.

[hueving]

>Look over the history of OpenSSH vulnerabilities and reduce them to the subset that could possibly have affected spiped and you'll see what I mean. spiped benefits from having less mechanism than OpenSSH.

This is true, but if you were using them to solve the same use-cases (fixed tunneling between hosts), how often would those OpenSSH vulnerabilities have been exploitable?

I apologize for arguing with you. The votes my comments are receiving have indicated to me that my input on this subject is not welcome in this community.

[tptacek]

Breathe. The downvotes you got (I wasn't one of them) indicated that people disagree with you. Probably by default, because they know who me and Colin are.

It's also a useful point that not all of OpenSSH's additional mechanism is implicated when doing point-to-point tunneling. But look at the actual vulnerabilities: some of them are!

[hueving]

>The downvotes you got (I wasn't one of them) indicated that people disagree with you. Probably by default, because they know who me and Colin are.

Doesn't that make you sad inside?