Why do Kaspa's keyed hash opcodes enforce strict key-length limits?

Kaspa's two keyed hash opcodes require keys of specific lengths because the underlying algorithms are mathematically designed to work only within those bounds. OpBlake2bWithKey accepts a key of at most 64 bytes, while OpBlake3WithKey requires a key of exactly 32 bytes — no more, no less. A keyed hash works like a regular fingerprint of your data, but stamped with a secret key so only someone holding that key can reproduce it; if the key is the wrong size, the algorithm's internal structure breaks down, which is why the rules are hard limits rather than suggestions. For anyone writing Kaspa scripts or integrating with its smart-contract layer, getting the key length wrong will cause the opcode to be invalid, so these limits are important to check before deploying.