Split message processing

[geonnave]

On top of PR #170. Aims to provide the split message processing discussed in issue #99.

Main tasks:

• split message processing
• some cleanup of the values stored in the outer state
• update to only pass cred_x later on (instead of when calling initiator/responder::new EDIT: tracked in Pass CRED_X later on #179
• update the examples

In addition, as a result of the split there is now IdCred and IdCredOwned. Thus,

• this should be made homogeneous. EDIT: tracked in Improve credential handling #178.

Finally, with respect to the EAD:

• integrate the refactored lake-authz EAD implementation
• implement add_eadX functions EDIT: tracked in Ability to prepare and process more than one EAD field #177

[chrysn]

A few comments inline.

From a final reviewing PoV, I'd hope to see the refactoring in shared and lib separated from the addition of an application, but that can be a split in the PR when it's going out of the draft stage (as keeping them split during development may incur excessive rebasing).

[geonnave]

Edit: the mapping of tasks in this comment have been moved to the first comment.

[geonnave]

This is ready for an initial review round. Note that the split begins at 5dd6c72 (previous commits are from PR #170).

[chrysn]

This looks to me like it's really independent of #170 (apart from commits such as 49cff1a that applies small fixes).

I'm not sure how you do / want reviews done here, but to me this would be way easier to review if the splitting changes could happen in a branch of their own. Depends a bit on the level of review you want here -- if it's more a rough look you're after, that works here as well. If you prefer commit-by-commit review, that might be more productive on a dedicated branch.

[chrysn]

Still mid-review, leaving some comments.

For context, the glass through which I'm looking at the code right now is git diff --ignore-all-space 5dd6c72^..geonnave/split-message-processing -- shared lib.

[chrysn]

How long does generating a key take? (I have no clue, can be just-take-the-few-bytes-of-entropy, can be do-some-complex-GF2-computations). If it's not trivial, it may be a good idea to store the x_or_y already in the Start, as that allows a system to prepare a key while not in use.

(Could also spin that out to an own low-prio issue)

[geonnave]

I only have data for preparing message 1, which as a whole takes about 20 ms, given these conditions: crypto initialisation is stateful (see #94); using the cc310 backend. So it is fast, although software backends might take longer.

[geonnave]

Thanks for the review so far. The type of review I am looking for is about the current state of the API and an overall rough look.

[chrysn]

I think the rough API is good from a high-level PoV. There are lots of details we can enhance, but we can do that progressively once this is in.

One thing probably makes sense to do now because it's a pain to do later: look through the newly introduce type and function names. (Now this can be one commit with grep -i s/.../.../ **/*.rs, later that's bound to cause merge conflicts). Particular candidates are the split functions that are now a and b variants. The process_message_n / prepare_message_n+1 split already works well, so maybe process_message_3a / process_message_3b can become parse_message_3 / verify_message_3, and prepare_message_3a / preparere_mesage_3b can become prepare_message_3 / finalize_message_3 (same for prepare_message_1a/b)

[geonnave]

Did changes suggested by @malishav (un-split prepare_message_1 and 3) and the renamings proposed by @chrysn.
Another critical item pointed by @malishav (private key accessed by application) is tracked in #182 and will be fixed ASAP.