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