On Sat, 14 Jul 2007 07:22:39 -0700, Larry Page <[log in to unmask]> wrote:

>Yes, we are trying to achieve PCI compliance, hence the requirement at 
>a data level.

So, you have a couple of options here, depending on whether you need to
know the PAN after the transaction has completed, or if you just use the
PAN for later authentication or identification of the user. The latter is as 
simple as creating a secure hash of the PAN for storage. The former means 
you do need to encrypt minimally the PAN but should encrypt additional
information as well.

In either case, most of these algorithms are block ciphers, working on
groupings of 128 bits at a time. If you have less than 128 bits of data
to encrypt, you still need to allocate 128 bits (16 bytes) of data for
each block, even if the source data is less than 128 bits. Further, if
less, you need to be very careful about how you create the remaining
bits to fill the block to 128 bits. Finding a good source of entropy
on the HP3000 is difficult. 

Are you able to redesign your database tables accordingly?

Regards,



M.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *