Third property of secrets

[dxoigmn]

One property of secrets that is missing from the current list of properties is that secrets should not be easily enumerable due to brute-force attacks. In the cryptography, for example, we usually want the key for a symmetric cipher to be at least 128-bits. This is threat model dependent, however, since smaller key sizes may be fine for short-lived applications. Perhaps the recommendation should be that authors of defensive papers that use secrets need to specify the cardinality of the secret space?

I see this in defensive schemes that uses JPEG compression where the compression level is assumed to be chosen uniformly at random between 0 and 100. That is an awfully small space that the adversary needs to enumerate even assuming independence between JPEG compression levels.

[carlini]

This is definitely true and worth adding. I had hoped to try to not completely enumerate all of the things you should and shouldn't do with secrets and make it exhaustive, but this seems important to add. Not sure if others have thoughts.

[anishathalye]

I agree that this would be a good addition, especially given that past papers have made this mistake before.

[jonasrauber]

In this particular case, I agree it’s worth adding

[npapernot]

This suggestion sounds worthwhile to add to the paper.

[wielandbrendel]

I'd also say it's worthwhile to add.

[ftramer]

I agree that it might be worth making this point explicit, but I just wanted to mention that it is actually implicitly implied by "(2): The secret must be nonextractable". In the JPEG example, the attacker can try 100 different attacks, see which one performs best, and thus "learn" the secret value used. Formally, if you define non-extractability as meaning that the adversary queries the system and then issues a guess which should only be correct with negligible probability, then the secret space must be exponential even if the adversary makes no queries.