Date: Mon, 25 Sep 2000 21:44:20 -0700 From: "Crist J . Clark" <cjclark@reflexnet.net> To: "Brian F. Feldman" <green@FreeBSD.ORG> Cc: Scot Elliott <scot@london.sparza.com>, CrazZzy Slash <slash@krsu.edu.kg>, Ali Alaoui El Hassani <961BE653994@stud.alakhawayn.ma>, freebsd-security@FreeBSD.ORG, Peter Pentchev <roam@orbitel.bg> Subject: Re: Encryption over IP Message-ID: <20000925214420.J59015@149.211.6.64.reflexcom.com> In-Reply-To: <200009251644.e8PGim554314@green.dyndns.org>; from green@FreeBSD.ORG on Mon, Sep 25, 2000 at 12:44:47PM -0400 References: <scot@london.sparza.com> <200009251644.e8PGim554314@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 25, 2000 at 12:44:47PM -0400, Brian F. Feldman wrote: > > I'm not sure that's the point. > > > > If you're using SSH to tunnel between two networks, across the public > > Internet then there is a chance of your encrypted datastream being > > intercepted and analysed. If there's a large amount of data then the > > chance of the key being found and therefore your unencrypted data exposed > > - is much higher. > > You still have to know at least some chunks of the plaintext to do that. > You simply _cannot_ brute force any moderately decent algorithm with > reasonable key length. For example, Blowfish (commonly) uses a 160 bit key. > To do 2^160 operations of anything in a reasonable amount of time would be > astounding, much less 2^160 different blowfish encryptions (note that it > takes about 26 operations to encrypt one byte of data; that does not take > into account the very low key agility which is much more significant for > being able to brute-force it). > > There aren't any chosen-plaintext or known-plaintext attacks against it; if > there were, you would still have to push that much data through the tunnel; > even chosen-plaintext attacks against a non-trivial algorithm require a huge > amount of data to be encrypted. In other words, don't worry about it. As the saying goes, if the encryption is the weakest part of your security scheme, you've got the most secure scheme in the world[0]. However, when using SSH to tunnel another protocol, it is quite possible that blocks of data that could be guessed and are repeated frequently in the output, something like a TCP header. That said, I confess that I have not examined how SSH uses fill to do its block encryptions. If it is sending each keystroke to the target machine, for example, you need to pad the data to send it. Now that I think about it I am not sure how it even deals with the block encryptions. (Dammit, now I am going to have to go find out.) Adding a timeout (or perhaps counting the bytes transfered) to generate a new key does not sound like it would be exceedingly difficult. All of the code to do it is already there. The tricky part will be designing the negotiations so that client and server can agree on a time for new keys and maintaining back-compatibility. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000925214420.J59015>