Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request From: David Lemson Newsgroups: comp.dcom.telecom Subject: Re: ATM at Retailers Message-ID: <12509@accuvax.nwu.edu> Date: 24 Sep 90 02:16:24 GMT Sender: news@accuvax.nwu.edu Organization: TELECOM Digest Lines: 27 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 672, Message 7 of 10 In a message of 23 Sep 90 16:49:02 GMT, Steven King writes: >In article <12439@accuvax.nwu.edu> kaufman@Neon.Stanford.EDU (Marc T. >Kaufman) writes: >>You are not giving your PIN number to the merchant. The PIN is >>encrypted (mixed with your bank card number) in a ONE WAY algorithm by >>a chip that is in the PIN pad itself. The plaintext PIN never sees >>the light of day. >A one way algorithm? Pray, how does the bank decode it to verify you? >A gigantic lookup table? The bank doesn't need to "decode" it. The bank's computer knows what your PIN is supposed to be. So, it codes it with the same trap-door algorithm as the keypad did, and compares the two. FYI, this is the same way that the Unix operating system encrypts passwords with a one-way coding scheme, and stores them encoded. My guess is that your bank's computer stores your PIN encoded, so it simply compares the encoded incoming message with the encoded number stored in the machine. David Lemson d-lemson@uiuc.edu