:-) You have a good point, I just assumed that decision had already been made. Here's 
:a visual representation of my point.

To hide A by turning it into B using algorithm object C and only someone with key D 
can see it.

C.encrypt(A,D) = B;
C.decrypt(B,D) = A;

If anyone has either part of C, or D you can consider your data compromised. However, 
a reasonably complex C and D will result in a B that will not be useful alone. 

In the case of PGP the encrypt and decrypt algorithms are public, either of which are 
a good start to breaking the encryption. Hence the considerable increase in complexity 
of their problem & the need for a more complex solution.

Every encryption method by nature boils down to obscurity. What cannot be kept private 
must be complex enough to provide sufficient security. Hence the name P(retty) G(ood) 
P(rivacy) ... Which is better, 128 bit encryption or 40? If you answered 128 you are 
correct, only because it introduces more complexity than the other.

Trivia Question: Why WAS it illegal to export strong encryption technology?
Answer: Export laws? Technically, but specifically the government wanted the ability 
to decrypt exported data in a timely fashion. 

You can believe it... or not.


<>< Ryan

-----Original Message-----
From: 1LT John W. Holmes [mailto:holmes072000@;charter.net]
Sent: Wednesday, October 23, 2002 2:33 PM
To: Ryan Jameson (USA); [EMAIL PROTECTED]
Subject: Re: [PHP-DB] Credit Card Info & Cryptography

When ever I see "easy", "encrypt", and "credit card" in the same sentence,
it makes me worry.

Don't store credit card numbers. Charge them once and don't save it

---John Holmes...

----- Original Message -----
From: "Ryan Jameson (USA)" <[EMAIL PROTECTED]>
Sent: Wednesday, October 23, 2002 4:20 PM
Subject: RE: [PHP-DB] Credit Card Info & Cryptography

Since your goal is to encrypt the card number in the database you'll
naturally need a way to decrypt it as well. At that point it seems your
concern is that your database will be compromised. That can be avoided
easily by creating a single private key and using your own algorithm to
encrypt based on that key. The only catch is, if the code that does the
encrypting is compromised, and the database is compromised, then the numbers
are compromised. My basic point is, your need is not the same as what PGP
addresses in that PGP addresses the more difficult problem of passing data
between 2 entities. Your requirement is very simple to address; 1. write a
simple compiled module with an embedded key, 2. keep that key in a safe
place, and 3. write another module to decrypt, all it needs is the key. This
is similar to what was done with DVDs, just don't allow your encryption
algorithms to be compromised. You can put the source code in the same place
as your key, you can use a code scrambler when you compile, and you should
already have your server secure already. Again, my point is, this is easy
because the same entity that encrypts is doing the decrypt. Hope this helps.

<>< Ryan

-----Original Message-----
From: Doaldo Navai Junior [mailto:doaldo@;triunfo-bsb.com.br]
Sent: Wednesday, October 23, 2002 12:53 PM
Subject: [PHP-DB] Credit Card Info & Cryptography

Suppose I sell some products online and get user's credit card info via SSL
connection. Isn't there any method (free, preferably) of ASSYMETRIC  (Public
key) cryptography I can use with PHP to store this data in a db?? Or is
there any other good option instead of this?


PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to