mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chris Friesen <cfriesen@nortelnetworks.com>
To: Oliver Xymoron <oxymoron@waste.org>
Cc: Jon Burgess <Jon_Burgess@eur.3com.com>,
	henrique@cyclades.com, linux-kernel@vger.kernel.org
Subject: Re: Problem with random.c and PPC
Date: Fri, 16 Aug 2002 16:52:49 -0400	[thread overview]
Message-ID: <3D5D6621.E33EA4BE@nortelnetworks.com> (raw)
In-Reply-To: <20020816195254.GL5418@waste.org>

Oliver Xymoron wrote:

> There is little to no reliably unpredictable data in network
> interrupts and the current scheme does not include for the mixing of
> untrusted sources. It's very likely that an attacker can measure,
> model, and control such timings down to the resolution of the PCI bus
> clock on a quiescent system. This is more than good enough to defeat
> entropy generation on systems without a TSC and given that the bus
> clock is a multiple of the processor clock, it's likely possible to
> extend this to TSC-based systems as well.

> Entropy accounting is very fickle - if you overestimate _at all_, your
> secret state becomes theoretically predictable. I have some patches
> that create an API for adding such hard to predict but potentially
> observable data to the entropy pool without accounting it as actual
> entropy, as well as cleaning up some other major accounting errors but
> I'm not quite done testing them.

The problem is this.  If you have an embedded system that is headless, diskless, keyboardless, and
mouseless, then your only remaining source of any interrupt-based entropy is the network.  Also, if
you add entropy to the pool without accounting it as entropy, then how does that help anything?  You
can currently add anything you want to the pool and it will stir it in but not bump the entropy
count.

Granted, a proper solution would involve a hardware-based system for entropy generation, but in the
absence of a proper solution you do the best you can.

For the general user, network-based interrupts are likely okay.  If you have an attacker
sophisticated enough that it can predict the arrival time of a network packet down to 30ns (the
timing of a 33MHz PCI bus) from across the network, then I think you will probably have the
resources for a hardware entropy generator.

This has been discussed many times, and the concensus seems to be that yes it is not secure, but
there are people who have literally no other option.

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

  parent reply	other threads:[~2002-08-16 20:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-16 10:00 Jon Burgess
2002-08-16 19:52 ` Oliver Xymoron
2002-08-16 17:51   ` henrique
2002-08-16 21:21     ` Ruth Ivimey-Cook
2002-08-17  0:47       ` Oliver Xymoron
2002-08-17  0:45     ` Oliver Xymoron
2002-08-17  6:05       ` Andreas Dilger
2002-08-17  7:23         ` Oliver Xymoron
2002-08-17  9:09           ` Andreas Dilger
2002-08-17 16:56             ` Oliver Xymoron
2002-08-19  9:29           ` Marco Colombo
2002-08-19 14:02             ` Oliver Xymoron
2002-08-19 15:11               ` Marco Colombo
2002-08-19 15:29                 ` Oliver Xymoron
2002-08-19 16:20                   ` Marco Colombo
2002-08-19 16:33                     ` Oliver Xymoron
2002-08-19 20:23                       ` Marco Colombo
2002-08-22  3:16             ` David Wagner
2002-08-16 20:52   ` Chris Friesen [this message]
2002-08-17  0:29     ` Oliver Xymoron
2002-08-22  3:19     ` David Wagner
2002-08-22 15:40       ` Chris Friesen
2002-08-22 17:25       ` Remco Post
  -- strict thread matches above, loose matches on Subject: below --
2002-08-15 16:10 henrique
2002-08-15 15:14 henrique
2002-08-15 18:25 ` Andreas Dilger
2002-08-15 19:03   ` Tom Rini
2002-08-15 19:59     ` Andreas Dilger
2002-08-15 21:04       ` Tom Rini
2002-08-16  1:50         ` H. Peter Anvin
2002-08-16 16:33           ` Oliver Xymoron
2002-08-16 16:28         ` Oliver Xymoron
     [not found]           ` <20020816170126.GD26993@opus.bloom.county>
2002-08-16 17:15             ` Oliver Xymoron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D5D6621.E33EA4BE@nortelnetworks.com \
    --to=cfriesen@nortelnetworks.com \
    --cc=Jon_Burgess@eur.3com.com \
    --cc=henrique@cyclades.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oxymoron@waste.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®