Tangle - cookie keys file
Gary E. Miller
gem at rellim.com
Fri Mar 8 06:29:01 UTC 2019
Yo Hal!
On Thu, 07 Mar 2019 21:21:01 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:
> Gary said.
> > I think it should be master key "K" and index "I" pairs. Only.
>
> The K includes the length. There are actually 3 algorithms that can
> be used on the wire or to make cookies. The wire has a slot for
> which algorithm to use. The internal API is to pass the same routine
> different key lengths.
OK. So?
> > Then you need a date/time with K/I pairs.
>
> You need that even if you aren't in ratchet mode. Consider a system
> that gets rebooted. How does ntpd know if it should switch to a new
> K now or in 24 hours?
Good, we agree.
> > I don't think any cookie should ever touch the file system.
>
> Ahhh...
>
> There is actually a paragraph in the draft that suggests saving a
> cookie on disk so you can get restarted without having to do the KE
> dance. I think it's marked SHOULD.
> There aren't any helpful
> comments about how to figure out when to save a new cookie.
I cant find that in the Proposed RFC. Got a citation?
And what is the point of storing cookies and K/I pair together? The
client has no K/I pair. A server is to regenerate the cookies from
K/I pairs. Mixing the roles is bad.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem at rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190307/2ad4eea2/attachment.bin>
More information about the devel
mailing list