encrypted string always the same

[Atom 'Smasher']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, 25 Aug 2004, Neil Williams wrote:

> On Wednesday 25 August 2004 1:30, Marius Andreiana wrote:
>> I saw everytime a text is encrypted with the same public key, the result
>> is different.
>
> Try encrypting using a symmetric cipher.
> from man gpg:
>     -c, --symmetric
>                 Encrypt  with  a symmetric cipher using a passphrase.  The
> default symmetric cipher used is CAST5, but
>                 may be chosen with the --cipher-algo option.
=================

that will still produce different output using the same input, because the 
user supplied passphrase is salted... try this a few times with the same 
passphrase, and you'll see different output:
 	echo test | gpg -ac


>> I'm trying to store gpg-encrypted values in a database, but would like
>> to be able to tell if a user-entered value matches the encrypted one in
>> database (by crypting it with the same public key).
>
> Wouldn't 'crypt' do the same thing? SQL already handles this using the
> password() function. It's a one-way encryption that just compares the
> encrypted hash, as stored in a suitable varchar field.
==================

that's also salted, but you can use it for password verification by 
specifying the salt.

understanding that this is insecure for several reasons (mostly the use of 
a 4 digit PIN), the easiest way to do this without making it *instantly* 
obvious (but it would be obvious within minutes) to an attacker, is to add 
a row to the database and store:
 		md5($pin)

an attacker can't use "81dc9bdb52d04dc20036dbd8313ed055" as a PIN, but you 
can use that to verify that a user's PIN is "1234".

of course, any system you use to hash a four digit pin can't be any 
stronger than searching the key-space of a four digit PIN... which is 
about a 13 bit key-space (will you advertise that this application uses 13 
bit security?). it's impractical to think you're safe from a dictionary 
attack, if the hashed passwords are lost or stolen... how long would it 
take to run:
 	for n in {0000..9999}
 	do
 		md5 -s $n
 	done

(that syntax works for zsh/freebsd; bash/linux will be slightly different)

on my modest desktop, it takes under a minute to search the entire 
keyspace...

even if you could encrypt PINs with a public key, without a salt, the 13 
bit key-space makes it trivial to find a collision... one would have to 
assume that an attacker has the public key. if making it more complicated 
doesn't make it more secure, then keep it simple. using a crypt() function 
in the database, instead of the md5 method described above, forces an 
attacker to spend 30 seconds on each PIN, instead of finding all PINs 
within 30 seconds... i'm not sure if that's a real advantage...


         ...atom

  _________________________________________
  PGP key - http://atom.smasher.org/pgp.txt
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"I'd like to share a revelation that I've had during
 	 my time here. It came to me when I tried to
 	 classify your species. I realized that you're not
 	 actually mammals. Every mammal on this planet
 	 instinctively develops a natural equilibrium with
 	 the surrounding environment, but you humans do not.
 	 You move to an area, and you multiply, and multiply,
 	 until every natural resource is consumed. The only
 	 way you can survive is to spread to another area.
 	 There is another organism on this planet that
 	 follows the same pattern. A virus. Human beings are
 	 a disease, a cancer of this planet, you are a
 	 plague, and we are the cure."
 		-- Agent Smith, The Matrix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJBLMFzAAoJEAx/d+cTpVciviQH/A8jz1n+reNRQxD3xHB3sNaT
oVeCgUEmTk6lfn4IT94iu9J6aemiSI14niUF6vK9FdsJSD6xC4a8MLg/gJbsUPvd
9um6OeXTAxknz71tCrmRISwCcsGNZwtmeEW62tykNFVGzUq7lJJxx0wCAD9QYoVB
xFQaukbZS/nz6y3wFnzmTNNcB/M+IOD64rRLW59vyfiNbEUVfOA4sKvKoKB2G9sD
UZtwBdMhiCDNEdDNXSbXFo7QE+pHiff73YzKNj+2QCx2+q2yn0adJ+vcskhKX0nA
up5taZl4EHCLE1ydF763lUleWwI52fP61SwH427wTIP9d6XCnQbjOqY9UlNymuU=
=1KuP
-----END PGP SIGNATURE-----