2 ms·
Just for the hell of it... > Why use an HMAC instead of a KMAC? First, SHA-3 (and thus KMAC) isn't particularly performant without hardware acceleration, and
by SAI_Peregrinus 6y ago
Just for the hell of it...
> Why use an HMAC instead of a KMAC?
First, SHA-3 (and thus KMAC) isn't particularly performant without hardware acceleration, and hardware acceleration (ASICs/special CPU instructions) isn't really available yet. So if you're not on an FPGA, KMAC will be slow.
Second, SHA-3 isn't available as a builtin in most libraries, so it requires another import.
Third, Blake2/Blake3 are faster in software and support similar MAC modes. So until hardware comes out with SHA-3 intrinsics that's a nicer alternative to HMAC.
> Why would anyone want to derive a key?
Lots of reasons!
You might need to derive a fixed-size key from a passphrase. This requires a password-based KDF, like Argon2 or scrypt.
You might need to derive a key from a field element like the result of a Diffie-Hellman exchange. The raw result isn't generally suitable for use as a key, since it's not likely the right size and might be biased.
You might need to derive a sequence of keys from an initial value, say to provide forward secrecy like Signal's double ratchet algorithm.
> When does it matter whether you use an integer or Galois field counter? Why bother calling it a GF when it's just binary anyway?
These two questions are related. Fields are used because they satisfy certain mathematical properties that the integers don't. Galois fields are used because they don't require floating-point or rational values, everything within them is an integer (of some special representation). We call it a GF element instead of an integer because it's not just binary any more than a .jpg image is just binary. It's representing something specific, and the usual arithmetic operations are implemented differently for elements of a field than they are in general. Many systems store the (binary) coefficients of rather high degree polynomials in the bits of an integer, and then add & multiply polynomials. The results will be different than if you added or multiplied the relevant integers, the operations share a name but are not identical. Others use things like elliptic curve points (with an X & Y coordinate), which clearly aren't integers even if both coordinates are.
> Why would I chose a protocol that used a symmetric cipher over an asymmetric one?
Symmetric ciphers are much, much faster.
Symmetric keys are much smaller.
Symmetric ciphers tend to be far easier to implement safely, and far more resistant to cryptanalitic attack. They're generally just safer.
- motohagiography 6y agoMostly 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