First NTS code

Hal Murray hmurray at megapathdsl.net
Mon Jan 28 03:05:14 UTC 2019


You have a couple of trailing spaces.

We should start collecting max/min/required lengths and references to where 
that number comes from.

Do we want to store cookies and passwords and such in a fixed max-size array 
or as heap allocated blobs?  In any case, we need to remember the lengths.

There are lots of places where we will be passing around c2s and s2c.  Maybe 
we need a struct for them (and lengths).

------

You should probably add a section for global variables for the server side.  
I'd call them nts_K and nts_I, using the names from RFC section 6
and nts_old_K and nts_old_I

Maybe the cookie stuff should be in a separate module.

We'll also need the AEAD algorithms we support and their crypto pointers.

----

#define NTS_COOKIES     8       /* RFC 4.1.6 */
I'd call that MAX_COOKIES

The client side needs:
  c2s and s2c, and lengths
  array of bools for which cookies are valid and another for unused.
  an array of cookie lengths.
  the AEAD algorithim we are using.  Probably 2 of them, the IETF number and 
the pointer to the crypto stuff.


The struct info needs to move from nts.c to nts.h
We need one per server, in the peer struct.

Your "empty cookie string as a sentinel" doesn't work unless you allocate 
space for the extra slot.

----------

nts_client_ke_request
nts_server_ke_verify

Those are poor names considering what you have them doing in the comments.
I would have picked nts_ke_client and nts_ke_server.

Actually, what you want at this level is nts_ke_server_start.  The actual 
per-client server processing is internal to the server.  It calls out to 
nts_new_cookie (8 times)

-----

The descriptions for nts_validate and nts_decorate seem fishy.  I think we 
need separate routines for client and server.
(that is 4 total)


-- 
These are my opinions.  I hate spam.





More information about the devel mailing list