Re: Network time protocol

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "FB" == Frank BENNETT <bennett@example.com> writes:

    FB> On Tue, Sep 19, 2000 at 02:07:39PM -0500, s-luppescu@example.com wrote:

    >> Theorically there is a problem when opening the NTP
    >> server. Many of the cryptographic systems use the system time
    >> to generate random numbers, and if 'attackers' can have access
    >> to your exactly system time, they theorically can break your
    >> cryptographic messages, etc. I recomment

Let's get serious; the attackers cannot get the exact system time.
What they can get is going to be plus/minus a few jiffies, and this is
going to be random unless (a) they own your kernel scheduler or (b)
you're using a coarse-grained time measure like Unix time.

But this is very bad, anyway.  The reason is that as a source of
randomness, time has none: it's a perfectly monotonic sequence.  As
long as your system runs close to UTC the attacker can cut down the
amount of "randomness" to _three_ bits (8 seconds) and even if you're
15 minutes off that's only 10 bits of randomness.  Even using personal
names for passwords has more security than that!

Conclusion: replace any crypto[sic] that depends on system time.

Kernel jiffies are another matter; they are much more fine-grained.
Still, I wouldn't use the current jiffie counter as a random seed.

    >> to close this to the internet, but if you don't run any
    >> PGP/GPG/SSL big programs or/and don't have big concern about
    >> your cryptography, it's okay to leave it open.

    FB> Wow again.  Reminds me of what Chuck Yaeger said about the
    FB> ejection seat in test aircraft: "A way of committing suicide
    FB> to keep from getting killed." I wonder what folks do about
    FB> this.

See linux/drivers/char/random.c.

    FB> I remember seeing a note recently about using some facility
    FB> other than the time for the entropy pool in encryption on
    FB> Linux systems.  Maybe this is only a concern if your
    FB> particular setup draws on the time.

The executive summary is that every time certain interrupts come in,
the kernel mixes in the time in jiffies since the last such interrupt.
The number of such additions to the entropy pool is monitored, and the
kernel refuses requests for random numbers unless the estimate of the
number of bits of entropy in the pool is greater than the number of
random bits requested.

Ted T'so believes "these numbers should be useful for the vast
majority of purposes."  That's good enough for me ;-)


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."