Date: Tue, 26 Sep 2000 12:10:03 +0200 From: Terje Elde <terje@elde.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: <20000926121003.G43065@dlt.follo.net> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Brian F. Feldman (green@FreeBSD.ORG) [000925 18:47]: > > 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). First of all, blowfish is most commonly used with a 128 bit key, not a 160 bit one. > 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. The point of re-keying isn't to avoid known plaintext or chosen plaintext attacks. The point is to help improve the situation should any component be broken. This includes the algorithm which might be vulnerable to unknown attacks, the PRNG might have made a bad judgement about it's entropy pool and given you a bad key once. Security isn't just about protecting from what you know are weaknesses in a system. Security is about protecting from anything, including what you don't know about. In my opinion re-keying is one step which will ease things quite considerably should anything break. It won't prevent most attacks, but it will help minimise the impact. Let's take an example. I'm running a system with a bad PRNG. It takes it's input from hashing incoming IP packets (or whatever). This allows you to control it, and because the mixing part isn't well designed either you manage to take control over the whole thing. I then start a ssh session, which will live on forever and feed data to this box from a remote one. Because you've broken my PRNG you manage to get the key. If you don't re-key you'll be able to read the data on the connection forever. With re-keying you'll loose that access with the next re-key after I get entropy not known to you. Terje -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE50HX48HLgLrwmRg0RAsHwAJ9qyZ8tGdc+vdQMvuTERklnBnTmygCgz8Rv 3wIG4mkUdWPbx79ce+t+Iu4= =lW85 -----END PGP SIGNATURE----- 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?20000926121003.G43065>