Mostly agree! If I were explaining these concepts to someone, I would lead with your answers, setting them up as problems where the thing I wanted to explain wa

Mostly agree! If I were explaining these concepts to someone, I would lead with your answers, setting them up as problems where the thing I wanted to explain was the solution. e.g. We need to prove to a counterparty that some data has not been tampered with, we're limited to the processing power of the IC on a smart card, and the whole protocol can't take more than a couple of seconds including network latency. Do we just self-assert the integrity of the message using an HMAC, or do we need to prove the data hasn't been replayed or injected? In the latter case, we might need an additional key/secret to verify that transaction integrity as well, implying KMAC. The part about counters gets weird, because it's unclear (to me) in some implementations whether the GF counter is supposed to act as an additional secret/diversification component with enough entropy to be a secret, implying that the function that generates it is also a cryptographic function, with a seed, which becomes in effect just another key to manage. Of course this could be a misunderstanding on my part as well, and without a BAN protocol diagram, it's hard to reason about. Some of the stuff I worked on, the designers basically kept nesting key management problems until people stopped listening. I've posted this a few times I think, but I share it with everyone, as it's a great reference for how these things are designed. http://www.lsv.fr/Software/spore/index.html http://www.lsv.fr/Software/spore/index.html