Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Sep 2000 16:21:03 +0200
From:      Terje Elde <terje@elde.net>
To:        James Wyatt <jwyatt@rwsystems.net>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: Encryption over IP
Message-ID:  <20000926162102.A55111@dlt.follo.net>
In-Reply-To: <Pine.BSF.4.10.10009260846290.20201-100000@bsdie.rwsystems.net>; from jwyatt@rwsystems.net on Tue, Sep 26, 2000 at 08:57:42AM -0500
References:  <20000926121003.G43065@dlt.follo.net> <Pine.BSF.4.10.10009260846290.20201-100000@bsdie.rwsystems.net>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* James Wyatt (jwyatt@rwsystems.net) [000926 16:05]:
> > 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.
> 	[ ... ]
> > 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.
> 
> But if "you can control [the PRNG]", don't you know it later? If you can
> only guess it once in a while, wouldn't rekeying give an attacking party
> more chances to try getting the key?

It I get entropy into the pool without you knowing then you no longer control
it.

You're somewhat right on the second issue though. It all boils down to
everything being a tradeoff. If someone can break my PRNG then I for one would
feel more comfortable rekeying as that will give you the ability to drop a bad
key. Sure, the risk is there that the attack starts after the initial key is
made and thus you allow the attacker to get a key he otherwise would not be
able to get. If you cannot know if you key have been taken or not, would you
rather bet the security of your entire communication on the first key being
good, or would you split things up to minimise the impact of an attack?

Also, there are other issues besides the effects of key compromise. The more
ciphertext you have to work with the better the chances are that the attack
will work in the first place for example.

> Also: What happens when your PRNG runs-out of entropy? If ssh stops or
> prevents login or rekeying, then you can have an outage and might not have
> the entropy to gen a key on login. If it doesn't, then couldn't an
> attacker replace or modify your PRNG to generate a fixed pattern? They
> might never need direct access to your host again.

You should never run out of entropy on a good system. If you do, then that
should not be a problem for a running session, as the running session should
simply keep using the old key until the new one is ready to use.

If an attacker is able to replace or modify your PRNG, then you've got bigger
problems anyway, as that requires root.

> Is there anything out there to ensure my PRNG is up to snuff or monitor it
> for BB or Spong? Is there any way I could graph the entropy pool with
> MRTG? I didn't see many hints in the egd doc. Should I care? - Jy@

The simple answer is that you probably don't have to care, others will do it
for you. If this is something that interests you then learning more is a good
choice.

Terje
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE50LDM8HLgLrwmRg0RAuXgAJ4vnfWLOSTllGhpMS5ud0bTKiuajQCeO+cB
N6PGoqYvK7oV8C6aYgCE51s=
=yZnb
-----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?20000926162102.A55111>