[noise] Questions regarding the Additional Symmetric Keys extension

[Mathias Hall-Andersen]

Hi, Noise

I have an updated draft for the ASK extension:
https://github.com/rot256/noise-extension-ask/raw/f392d5e7aa48501c4e41b58ecf58ee8a077128d6/output/ask.pdf

These are noteworthy changes:

Removal of EnableASK, enable_ask and ask_master.
The API now only has 2 methods.

Make the InitASK (previously "generate_chains") per label (rather than taking a set) to:
- Simplify use when different ASK chains are generated based on conditional logic.
- Simplify implementation:
  e.g. the C function signature becomes:
	init_ask(uint8_t *label, size_t len), rather than 
        init_ask(uint8_t **label, size_t* len, size_t elems)

Truncate GetASK (previously "invoke_chain") output to 32 bytes to ensure 
identical behavior independent of the Crypto functions used.
Collision resistance can be obtained by concatenation of outputs (from the same or different chains).


Further considerations / discussion:

Maybe we should not reset the chains at all (after MixKey/MixKeyAndHash calls), this would:
1. Simplify implementation even further: no modification (at all) is required for MixKey/MixKeyAndHash.
2. Allow the derivation of further keys based on previous state (I can not think of a use case).


Maybe we should derive the first ASK output in the HKDF call that also instantiates the chain:
The most likely use-case for ASK is the derivation of a single key per chain, 
by generating the first output together with the chain:

"""
first_output, ask_chain = HKDF(ck,  h || label, info="ask", 2)
"""

We would save a HKDF call and allow highly optimized/specialized 
implementations wishing to only generate a single output per chain to instead implement the ASK extension as:

"""
first_output = HKDF(ck, h || label, info="ask", 1) # no chain is used, still compatible with full ASK implementation.
"""

Which is about the best you can do in terms of computational effort.
However this might complicate implementation of the extension.


Better names for the API is still a priority.

- Mathias