Perry E. Metzger wrote: >But if you can't simulate the system, that implies that the challenger >has to have stored the challenge-response pairs because he can't just >generate them, right? That means that only finitely many are likely to >be stored. Or was this thought of too?
I believe the idea is that there are gazillions of possible challenges. The challenger picks a thousand randomly in advance, scans the token from the corresponding thousand different angles to get the thousand responses, and stores all them. Then, later, the challenger can select one of his stored challenges, pass it to a remote entity, and demand the correct answer. Of course, a challenger must never re-use the same challenge twice. I find the physical token a poor replacement for cryptography, when the goal is challenge-response authentication over a network. In practice, you never really want just challenge-response authentication; you want to set up a secure, authenticated channel to the other party, which means you probably also need key distribution functionality. The physical token suggested here doesn't help with that at all. It seems to me the real value of the physical token is that it provides a piece of hardware that is (hopefully) very expensive to clone. That's an interesting capability to have in your bag of tricks. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
