From owner-freebsd-security Mon Sep 25 21:44:41 2000 Delivered-To: freebsd-security@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 3424437B424; Mon, 25 Sep 2000 21:44:34 -0700 (PDT) Received: from 149.211.6.64.reflexcom.com ([64.6.211.149]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 25 Sep 2000 21:43:13 -0700 Received: (from cjc@localhost) by 149.211.6.64.reflexcom.com (8.11.0/8.11.0) id e8Q4iLw69493; Mon, 25 Sep 2000 21:44:21 -0700 (PDT) (envelope-from cjc) Date: Mon, 25 Sep 2000 21:44:20 -0700 From: "Crist J . Clark" To: "Brian F. Feldman" Cc: Scot Elliott , CrazZzy Slash , Ali Alaoui El Hassani <961BE653994@stud.alakhawayn.ma>, freebsd-security@FreeBSD.ORG, Peter Pentchev Subject: Re: Encryption over IP Message-ID: <20000925214420.J59015@149.211.6.64.reflexcom.com> Reply-To: cjclark@alum.mit.edu References: <200009251644.e8PGim554314@green.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200009251644.e8PGim554314@green.dyndns.org>; from green@FreeBSD.ORG on Mon, Sep 25, 2000 at 12:44:47PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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