Adding parameters to sponge's capacity

Question

Is it safe to XOR parameters like domain, length of the message or block counter into sponge's capacity or that gives attacker control over capacity?

For example NORX XORs domain into capacity.

Does this break sponge security proofs?

What about adding bit into capacity to denote that there was no padding since message was multiple of rate and therefore reducing number of permutation function executions?

PRIMATEs use padding spilling which is similar to no-padding bit. Their paper says:

Note that the spilling of the padding in case |M[w]| = r causes security to degrade by half a bit: intuitively, APE is left with a capacity of c' = c - 1.

However, it looks like this doesn't apply to HANUMAN and GIBBON which also use the same padding spilling.

Answer 1

It is safe to xor parameters into the sponge as long as they are uniquely encoded so that they can't be confused with part of a message. The same goes for padding: if two distinct messages are treated the same way because you skipped padding, you're in trouble; e.g., if you use a length prefix then no padding at the end is necessary but you need to know the length up front.

This is not like JWT where the adversary can change one part of the JSON like the algorithm tag to control what algorithm the receiver uses to verify the rest of the JSON: you can't recover parameters from a hash anyway if it's worth its salt as a hash, so legitimate users aren't even temped to do that.

Even better, hashing the parameters means that an adversary can't reuse a hash made with one set of parameters for an application that uses another set of parameters—hashing the parameters makes the hashes used by the two applications essentially independent.

As a pathological example of how this could go wrong, imagine a protocol where one part uses $\operatorname{SHA-256}(x)$ as a public identifier for something, and another part uses $\operatorname{SHA-256}(\operatorname{SHA-256}(x))$ as a secret, each of which use is independently essentially fine (except for potential generic issues with $H^2$). Obviously this combination of uses could be exploited to learn the secret. Were the number of iterations of SHA-256 hashed into the message, as in $\operatorname{SHA-256}(1 \mathbin\| x)$ and $\operatorname{SHA-256}(2 \mathbin\| \operatorname{SHA-256}(2 \mathbin\| x))$ instead, there would be no such danger.