PDF《Cryptographic Agility》

1 and (x, y) otherwise. It'

s just like the previous game, but with two function families, and both are being evaluated with the same key. We say that the pair {F1, F2} is agile if an adversary can'

t guess b in the above game. Now consider the following statement or conjecture: wPRF-A : Every pair {F1, F2} of wPRFs is agile. Is the statement true? Our ?rst guess was yes, because the randomness of the inputs means the two functions are unlikely to ever be evaluated on the same point, and then it is hard to see what harm there is in their using the same key. But attempts to prove this failed. It is unclear how to reduce the agility of {F1, F2} to their individual, assumed wPRF securities because reduction-based proof methods break down totally when the key is the same for both functions. Does that mean the statement is false? To demonstrate that, we need a counter-example, meaning speci?c families F1, F2 that (under some assumption) are wPRFs but we have an attack showing {F1, F2} is not agile. However, an example is not immediate, again due to the fact that the attacker has no control on the inputs to the functions, these being chosen at random by the game. We clarify that the question is not whether there exists a pair {F1, F2} that is agile. We are not asking for a construction of F1, F2 that can securely share a key. Indeed, such a construction is trivial: just let F be a wPRF and let F1 = F2 = F. The question is whether all pairs {F0, F1} of wPRFs are agile. We have still to motivate why we should care whether security is maintained when two schemes use the same key, a practice that cryptographers would typically frown upon. But we will soon explain important practical reasons for t........