| an analogy i've used recently with respect to userid/password paradigm, | is that account numbers are being concurrently used for both the userid | function (requiring security *integrity* but not security | *confidentiality*) as well as the password function (requiring strong | security *confidentiality*). as a result there are frequently | diametrically opposing requirements where the muiltitude of userid-type | business functions require access to the account number ... at the same | time, the password-type functions require that the account number be | kept strictly *confidential* and not be available at all.... If this is all you need, then using a 1-way hash of the card number for identification and the card number itself for security would give you much of what you need. There are databases out there which identify customers by their CC numbers, not because they are willing to use the stored CC number for charging, but just becauses it's a good unique ID. If what were stored were the 1-way hash, there would be nothing worth stealing in the database.
This kind of thing is actually implemented, though people rarely think of it in these terms. You can see it on many printed charge slip these days: Your CC number no longer appears, being replaced by a one-way hash that produces 12 X's and the last 4 digits of your number. Hardly cryptographically strong in the usual sense, and not generally applicable, but for ID purposes - letting you identify which of your cards you used when making the charge - this particular one-way hash is perfectly good. (It's also common on Web forms that tell you which of your cards a charge will be applied to.) -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]