encrypted string always the same

Atom 'Smasher' atom at suspicious.org
Wed Aug 25 18:42:21 CEST 2004

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:

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}
 		md5 -s $n

(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 

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...


  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
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures


More information about the Gnupg-users mailing list