[ILUG] gpg encryption query...

[Smelly Pooh]

In reply to kevin lyda's flatulent wordings, 
> considering the western union issue with stolen cc's i'm wondering
> what might be a good way to store a database of cc numbers.

In encrypted format of course :}

> for pretty much any cc processing application there are the following
> two needs.
> 
>     there's a need to see if a new cc number is in the db.
>     there's a need to extract the cc's once a day.
> 
> now if it wasn't for the last issue, you could do an md5 encryption on
> the cc.  you wouldn't be able to see it again, but you can just encrypt
> the incoming cc and compare with it.  so i tried using gpg on a small
> text file twice and the results were different each time.  that makes
> sense since gpg/pgp only use their public key algorithms to encrypt a
> password for another (faster) cypher.

It's not necessary for the file to change each time in public key encryption,
you can reuse the same random numbers (or session key generated from said
random numbers that you pass to your secret key cipher) and hence get the same
encrypted file, that's a bad thing for a couple of reasons.  It gives somebody
more time to try and crack your session key and have access to everything you
send, and it makes you susceptible to replay attacks (an old example is if you
have tapped a bank line for wiring credit transfers, you can send yourself 20
quid, sniff the encrypted packet, and then replay it for as many 20 quidders
as you like, although I hope that isn't applicable in real life)

> can gpg or any other linux based public key algorithm be convinced to
> encrypt using only the public key algorithm?

For starters, GPG isn't a public key algorithm, it's a program that uses a few
public key algorithms.  It is viable to encrypt using public key algos.
exclusively, but I can't think of an instance where it is preferable over a
public key/secret key hybrid.  I thought you wanted the encrypted file to look
the same each time you encrypted anyway?

> the tough requirement here is that speed *is* an issue though it is a small
> amount of data.  are there other ways i'm not thinking of to do this?

You won't get speed using only public crypto.  You remember when you generate
your initial public keys under PGP/GPG (or even under RSA authentication in
SSH) and how long it takes?  That varies between 512-bits to 2048-bits
these days and two prime numbers of above lengths are generated for every
block (with pure and secure public key encryption of a stream).  Calculating
prime numbers of this size at every block takes a lot lot lot longer than
using a secret key cipher which only involves bit operations over 56-bit to
256-bit blocks.

To be honest though, I don't know exactly what you're trying to do that you
need the files to be encrypted the same way each time, care to elaborate?