W3C home > Mailing lists > Public > ietf-tls@w3.org > April to June 1996

Re: Merged Transport Layer Protocol Development

From: Bennet Yee <bsy@cs.ucsd.edu>
Date: Wed, 24 Apr 1996 15:16:31 -0700
Message-Id: <199604242216.PAA07915@work.ucsd.edu>
To: Dan Simon <dansimon@microsoft.com>
Cc: "'ietf-tls@w3.org'" <ietf-tls@w3.org>

In message <c=US%a=_%p=msft%l=RED-92-MSG-960424195112Z-26742@tide21.microsoft.c
om>, Dan Simon writes:
> UNIX time was not removed so that challenges would be more random, but
> rather to preserve available randomness resources.  UNIX time on a
> machine may reasonably be expected to contain, say, 3 bits of entropy,
> if not sampled too often.  This may not sound like much, but when
> you're trying to harvest entropy from a PC for psuedorandom generator
> seeding, you need every bit you can scrounge.  Publicizing this value
> on a regular basis takes away its value as a contributor to this
> process.  On the other hand, given the ease (and frequency) with which
> time is reset on many machines, its value as a source of pure
> non-repeatability for challenges (as opposed to randomness) is, in my
> view, negligible.

All modern Unix systems provide the time on the daytime port (TCP port
13, also UDP port 13, RFC 867 / STD 25).  Perhaps Windows machines,
being more recently network-aware, do not yet offer this common
service (along with echo, chargen, etc services) as standard
configuration.  While I have not checked into it, I would imagine that
any complete TCP stack implementation for Windows would include these
kinds of common services.

So while the daytime service is not a _required_ service per se, it is
so often provided that expecting much secrecy of the _precise_ time
value is probably inappropriate.  (Figuring out the value to second
resolution is not hard when network latencies range from a few to a
hundred millisecond.)

Furthermore, many machines use the Network Time Protocol (see RFC
1589) to automatically synchronize their internal clocks with the US
time standard and automatically account for hardware clock drift.
While this is not a requirement for Internet-aware machines either, it
is not uncommon, and it is very likely to lower the amount of hardware
drifts / clock jitter that may be available/accessible to a user-level
program.  While the clock chip is accessible directly from non-NT
versions of Windows -- and thus the uncorrected values would be
available -- building in such an expectation of being able to use it
as a source of randomness implies more kernel-level mods / new
installable-drivers for several commercial OSes.

Additionally, it's not clear to me at all that the conjectured 3 bits
of randomness is self-refreshing, i.e., whether it is used up on the
first sampling or whether more randomness is available after one waits
a while (and how long?).  Clock chips may have spec'd variance within
a batch, and certainly the clocks may drift over time (at some spec'd
rate), but the variance over time in the rate of drift for a
particular chip may be very small.  Certainly the manufacturer specs
only provide bounds that go the wrong way for this application!


Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114
Received on Wednesday, 24 April 1996 18:16:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:58 UTC