5

In many cryptographic games, the adversary doesn't seem to be parameterized by the security parameter.‡ Are such games equivalent to variants in which the adversary is parameterized by the security parameter?‡‡

‡ E.g., Bellare et al.'s IND-CPA (Crypto'98) defines: $(pk,sk) \leftarrow K(1^k)$; $(x_0,x_1,s) \leftarrow A_1(pk); ...$, i.e., $A_1$ isn't taking $1^k$.

‡‡ E.g., is the game above equivalent to: $(pk,sk) \leftarrow K(1^k)$; $(x_0,x_1,s) \leftarrow A_1(pk,1^k); ...$.

user2768
  • 357
  • 4
  • 15
  • If you mean "making the adversary depend on the seu-curity parameter", you may want to look into the notion of non-uniformity. – fkraiem Jun 22 '16 at 16:10
  • I meant is A(k) more powerful than A(), where k is a security parameter and A is the adversary. I suspect they are not, but I don't understand why. Perhaps A() can find k by brute force, thus k isn't needed. Or ... – user2768 Jun 22 '16 at 16:59
  • What do you mean by "more powerful"? – fkraiem Jun 22 '16 at 17:13
  • @user2768 Can you give an example of a scheme in which A() is not taking the security parameter as an input? – curious Jun 22 '16 at 20:31
  • @fkraiem, "more powerful" as in can A() simulate A(k)'s challenger. – user2768 Jun 23 '16 at 07:36
  • @curious, added above – user2768 Jun 23 '16 at 07:44
  • This is not at all what a parameter means, here you mean input. – fkraiem Jun 23 '16 at 07:48
  • @fkraiem, I only use security parameter, so I suppose you mean: "This is not at all what [parameterized] means, here you mean input." I suppose that depends on the definition of parameterized. I've used it as a synonym for input. Input is certainly more standard, so I have edited. – user2768 Jun 23 '16 at 08:09
  • Again, a parameter and an input are two very different things, there is no question of one being "more standard". (Your link is wrong, by the way.) – fkraiem Jun 23 '16 at 08:11
  • Actually, I think my usage is correct. Inputting would only permit the case $A_1(pk,1^k)$, whereas $A_1$ could be parameterized elsewhere. That is to say, "the adversary doesn't seem to be parameterized by the security parameter [but perhaps I'm missing something]." (It is quite clear that the adversary doesn't input the security parameter. But does the adversary know it? Or can the adversary compute it?) – user2768 Jun 23 '16 at 08:15

1 Answers1

3

The adversary should definitely always be "allowed to know" the security parameter. In other words, a security definition should allow the adversary's behavior to depend on the security parameter. This can be accomplished either by quantifying the adversary after the security parameter is chosen, or by letting the security parameter be an explicit input to the adversary.

The alternative would fly in the face of Kerckhoff's principle -- since the adversary is not allowed to "know" the security parameter, it would mean that the scheme is (apparently) deriving some important property from the secrecy of the security parameter.

Nonetheless, here are some valid reasons why this dependence on security parameter might be omitted in the notation:

  • Authors are lazy, the extra parameter to the adversary is cumbersome to write, and the intended audience probably knows the standard conventions about security parameters.

  • In an earlier section, authors have said "all algorithms are assumed to take a global security parameter as common input" or something along those lines.

  • The adversary already gets to see certain things from which it could infer the security parameter anyway. So it is redundant to give the security parameter explicitly. For example, the adversary sees a public key in some security game, and the length of the public key is the security parameter. Especially in things like public-key crypto, it is without loss of generality that you include the security parameter in the public key.

Mikero
  • 13,187
  • 2
  • 33
  • 51