| 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

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]

Reply via email to