Date: Mon, 25 Jun 2012 14:59:05 -0700 From: Doug Barton <dougb@FreeBSD.org> To: RW <rwmaillists@googlemail.com> Cc: freebsd-security@freebsd.org Subject: Re: Hardware potential to duplicate existing host keys... RSA DSA ECDSA was Add rc.conf variables... Message-ID: <4FE8DF29.50406@FreeBSD.org> In-Reply-To: <20120625223807.4dbeb91d@gumby.homeunix.com> References: <CA%2BQLa9A4gdgPEn3YBpExTG05e4mqbgxr2kJ16BQ27OSozVmmwQ@mail.gmail.com> <86zk7sxvc3.fsf@ds4.des.no> <CA%2BQLa9Dyu96AxmCNLcU8n5R21aTH6dStDT004iA516EH=jTkvQ@mail.gmail.com> <20120625023104.2a0c7627@gumby.homeunix.com> <86pq8nxtjp.fsf@ds4.des.no> <20120625223807.4dbeb91d@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/25/2012 02:38 PM, RW wrote: > On Mon, 25 Jun 2012 18:09:14 +0200 > Dag-Erling Smørgrav wrote: > >> RW <rwmaillists@googlemail.com> writes: >>> Dag-Erling Smørgrav <des@des.no> writes: >>>> You do know that these keys are used only for authentication, and >>>> not for encryption, right? >>> I'm not very familiar with ssh, but surely they're also used for >>> session-key exchange, which makes them crucial to encryption. They >>> should be as secure as the strongest symmetric cipher they need to >>> work with. >> >> No. They are used for authentication only. This is crypto 101. > > It also generates a shared secret for key exchange, which is pretty > much what I said. It's one of the elements included, yes. But having the host's secret key is not going to allow you to do anything other than impersonate the host. See https://tools.ietf.org/html/rfc4253#section-7 >> Having a copy of the host key allows you to do one thing and one thing >> only: impersonate the server. It does not allow you to eavesdrop on >> an already-established connection. > > It enables you to eavesdrop on new connections, Can you describe the mechanism used to do this? > and eavesdroppers > are often in a position to force reconnection on old ones. If you can get on the network link between the client and the host, yes, you can force an existing connection to drop. But that doesn't require the host's secret key. >> If the server is set up to require key-based user authentication, an >> attacker would also have to obtain the user's key to mount an >> effective man-in-the-middle attack. > > If an attacker is only interested in a specific client, it may not be > any harder to break the second public key, than the first one. Well that's just plain nonsense. The moon "may" be made of green cheese. :) But there are so many holes in that statement in regards to the original proposition that it's hardly worth the electrons it's printed on.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FE8DF29.50406>