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