[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: time and date
Carl Ellison writes:
>As one person wrote to me, off the list, it will be a long time before he
>has hardware capable of doing an RSA verification in a millisecond --
Agreed. If you need a millisecond or microsecond resolution,
you're probably going to be doing a large number of operations,
so you can use SPKI to certify keying information for faster protocols.
For instance, you might send the end of an 10000-entry S/Key hash chain,
signed by an SPKI-verified key, and send each additional entry
in the chain with whatever material needs to be verified.
If that's too serial for your application, you might send a
pile of a few thousand DES keys, signed by an SPKI-verified key,
and use the DES keys to encrypt the commands.
Or just use keyed hashes, with the key verified by SPKI.
>I'm not convinced that it's possible to sync clocks.
>I know the time protocol claims to do that, but it assumes that the
>one-way internet propagation time is 1/2 the round trip time, since it can
>measure only the round trip time.
You're not always going to be teleoperating equipment on the moon.
You may be communicating across the city, or across the room.
You may be on the jittery Internet, or you may be on a token ring LAN,
or you may be teleoperating across the ocean to a machine with an
atomic clock that was set identically with yours before shipping
and has been using the Net to keep sync over longer periods of time.
Or you may be doing some application that only cares about relative times,
or that only cares about overall speed and can handle a few ms latency.
Another interesting activity that _might_ want high-speed
certification is audio teleconferencing, where you want to know
that whoever is speaking is the person you expect;
encryption can do this if you can trust the bridge and
pick the right protocols, but may be overkill.
Bill Stewart, firstname.lastname@example.org
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639