On 12 Jan 2000, Niels M�ller wrote:
> Section "What LSH is": http://www.lysator.liu.se/~nisse/lsh is not really an
> lsh "site". It's a gateway to my cvs repository. At top level, it
> displays the README file and a directory listing.
fixed.
> Section "The concept of public key encryption": Note that lsh and
> secsh doesn't really use public key _encryption_. It only uses digital
> signatures, and diffie-hellman keyexchange.
fixed. Wasn't sure about that, not having gone over the actual protocol.
That makes more sense than what I was envisioning, because what I was
envisioning wouldn't work if the user didn't have a key pair.
I changed encryption to cryptography in the section title, and described
signing a little bit better (I think, I've got some crypto theory, but I'm
not an expert).
> There's no RFC. Latest drafts are from last summer. I'm sad to say
> that the IETF working group is not very active. But there seems to be
> work going on elsewhere; the latest drafts appeared and addressed some
> problems in earlier drafts, although there were almost no discussion
> on the wg mailing list.
So noted. Not in the position to play activist yet.
> If there is any serious security problem in lsh, I would expect it to
> be of one of this types:
>
> 1. Standard buffer overflow bugs. ...
> 2. Subtly flaws, say a bug in the randomness code ...
> 3. Denial of service attacks, ...
Which is what I expected, just about in reverse order of their likelyhood.
I know that DOS attacks can exist, at least with lshd running under
FreeBSD, as I've crashed lshd repeatedly learning how to set it up.
> It is an interesting observation that you get some protection from
> MITM-attacks by using authorized user keys and sloppy host
> authentication.
>
> But it is not what I would recommend. For a start, the usual way to
> authorize a user key is to copy some data from the client to the
> server. The transfer need not use encryption, but it *must* use proper
> authentication. So you usually need a properly authenticated
> connection to the server first.
I agree wholeheartedly. In the section that I discuss host key
generation, right after the command for key key generation, I tell how to
generate the fingerprint, and state that getting that fingerprint to the
users of LSH would be a nice courtesy.
I was specifically asking about it for the case where you don't have the
fingerprint because someone else set up the server you're connecting to,
and didn't disseminate the fingerprint. I thought that authorized user
keys would provide some protection, but I wasn't sure of how much. I can
imagine situations where it wouldn't help, though they're rather
contrived, but that doesn't mean that there aren't non-contrived
situations where it wouldn't help.
