The pgcrypto module provides cryptographic functions for PostgreSQL.
This is the original pwdump program. It is mostly of historical value these days. You will likely want to use a newer reimplementation such as pwdump6 instead. You might also be interested in our file archive with local copies of many pwdump-like and pwdump-related programs. Pwdump2 by Todd Sabin of Bindview Windows NT/2000, free.
F.20.1. General hashing functions
F.20.1.1. digest()
Computes a binary hash of the given data. type is the algorithm to use. Standard algorithms are md5, sha1, sha224, sha256, sha384 and sha512. If pgcrypto was built with OpenSSL, more algorithms are available, as detailed in Table F-21.
If you want the digest as a hexadecimal string, use
encode()
on the result. For example:F.20.1.2. hmac()
Calculates hashed MAC for data with key key. type is the same as in
digest()
.This is similar to
digest()
but the hash can only be recalculated knowing the key. This prevents the scenario of someone altering data and also changing the hash to match.If the key is larger than the hash block size it will first be hashed and the result will be used as key.
F.20.2. Password hashing functions
The functions
crypt()
and gen_salt()
are specifically designed for hashing passwords. crypt()
does the hashing and gen_salt()
prepares algorithm parameters for it.The algorithms in
crypt()
differ from usual hashing algorithms like MD5 or SHA1 in the following respects:- They are slow. As the amount of data is so small, this is the only way to make brute-forcing passwords hard.
- They use a random value, called the salt, so that users having the same password will have different encrypted passwords. This is also an additional defense against reversing the algorithm.
- They include the algorithm type in the result, so passwords hashed with different algorithms can co-exist.
- Some of them are adaptive — that means when computers get faster, you can tune the algorithm to be slower, without introducing incompatibility with existing passwords.
Table F-18. Supported algorithms for
crypt()
Algorithm | Max password length | Adaptive? | Salt bits | Description |
---|---|---|---|---|
bf | 72 | yes | 128 | Blowfish-based, variant 2a |
md5 | unlimited | no | 48 | MD5-based crypt |
xdes | 8 | yes | 24 | Extended DES |
des | 8 | no | 12 | Original UNIX crypt |
F.20.2.1. crypt()
Calculates a crypt(3)-style hash of password. When storing a new password, you need to use
gen_salt()
to generate a new salt value. To check a password, pass the stored hash value as salt, and test whether the result matches the stored value.Example of setting a new password:
Example of authentication:
This returns true if the entered password is correct.
F.20.2.2. gen_salt()
Generates a new random salt string for use in
crypt()
. The salt string also tells crypt()
which algorithm to use.The type parameter specifies the hashing algorithm. The accepted types are: des, xdes, md5 and bf.
The iter_count parameter lets the user specify the iteration count, for algorithms that have one. The higher the count, the more time it takes to hash the password and therefore the more time to break it. Although with too high a count the time to calculate a hash may be several years — which is somewhat impractical. If the iter_count parameter is omitted, the default iteration count is used. Allowed values for iter_count depend on the algorithm:
Table F-19. Iteration counts for
crypt()
Algorithm | Default | Min | Max |
---|---|---|---|
xdes | 725 | 1 | 16777215 |
bf | 6 | 4 | 31 |
For xdes there is an additional limitation that the iteration count must be an odd number.
To pick an appropriate iteration count, consider that the original DES crypt was designed to have the speed of 4 hashes per second on the hardware of that time. Slower than 4 hashes per second would probably dampen usability. Faster than 100 hashes per second is probably too fast.
Here is a table that gives an overview of the relative slowness of different hashing algorithms. The table shows how much time it would take to try all combinations of characters in an 8-character password, assuming that the password contains either only lowercase letters, or upper- and lower-case letters and numbers. In the crypt-bf entries, the number after a slash is the iter_count parameter of
gen_salt
.Table F-20. Hash algorithm speeds
Algorithm | Hashes/sec | For [a-z] | For [A-Za-z0-9] |
---|---|---|---|
crypt-bf/8 | 28 | 246 years | 251322 years |
crypt-bf/7 | 57 | 121 years | 123457 years |
crypt-bf/6 | 112 | 62 years | 62831 years |
crypt-bf/5 | 211 | 33 years | 33351 years |
crypt-md5 | 2681 | 2.6 years | 2625 years |
crypt-des | 362837 | 7 days | 19 years |
sha1 | 590223 | 4 days | 12 years |
md5 | 2345086 | 1 day | 3 years |
Notes:
- The machine used is a 1.5GHz Pentium 4.
- crypt-des and crypt-md5 algorithm numbers are taken from John the Ripper v1.6.38 -test output.
- md5 numbers are from mdcrack 1.2.
- sha1 numbers are from lcrack-20031130-beta.
- crypt-bf numbers are taken using a simple program that loops over 1000 8-character passwords. That way I can show the speed with different numbers of iterations. For reference: john -test shows 213 loops/sec for crypt-bf/5. (The very small difference in results is in accordance with the fact that the crypt-bf implementation in pgcrypto is the same one used in John the Ripper.)
Note that 'try all combinations' is not a realistic exercise. Usually password cracking is done with the help of dictionaries, which contain both regular words and various mutations of them. So, even somewhat word-like passwords could be cracked much faster than the above numbers suggest, while a 6-character non-word-like password may escape cracking. Or not.
F.20.3. PGP encryption functions
The functions here implement the encryption part of the OpenPGP (RFC 4880) standard. Supported are both symmetric-key and public-key encryption.
An encrypted PGP message consists of 2 parts, or packets:
- Packet containing a session key — either symmetric-key or public-key encrypted.
- Packet containing data encrypted with the session key.
When encrypting with a symmetric key (i.e., a password):
- The given password is hashed using a String2Key (S2K) algorithm. This is rather similar to
crypt()
algorithms — purposefully slow and with random salt — but it produces a full-length binary key. - If a separate session key is requested, a new random key will be generated. Otherwise the S2K key will be used directly as the session key.
- If the S2K key is to be used directly, then only S2K settings will be put into the session key packet. Otherwise the session key will be encrypted with the S2K key and put into the session key packet.
When encrypting with a public key:
- A new random session key is generated.
- It is encrypted using the public key and put into the session key packet.
In either case the data to be encrypted is processed as follows:
- Optional.For RSA encryption you must create either DSA or RSA sign-only key as master and then add an RSA encryption subkey with gpg --edit-key.To list keys:To export a public key in ascii-armor format:To export a secret key in ascii-armor format:You need to use
dearmor()
on these keys before giving them to the PGP functions. Or if you can handle binary data, you can drop -a from the command.For more details see man gpg, The GNU Privacy Handbook and other documentation on http://www.gnupg.org.
F.20.3.9. Limitations of PGP code
- No support for signing. That also means that it is not checked whether the encryption subkey belongs to the master key.
- No support for encryption key as master key. As such practice is generally discouraged, this should not be a problem.
- No support for several subkeys. This may seem like a problem, as this is common practice. On the other hand, you should not use your regular GPG/PGP keys with pgcrypto, but create new ones, as the usage scenario is rather different.
F.20.4. Raw encryption functions
These functions only run a cipher over data; they don't have any advanced features of PGP encryption. Therefore they have some major problems:
- They use user key directly as cipher key.
- They don't provide any integrity checking, to see if the encrypted data was modified.
- They expect that users manage all encryption parameters themselves, even IV.
- They don't handle text.
So, with the introduction of PGP encryption, usage of raw encryption functions is discouraged.
Encrypt/decrypt data using the cipher method specified by type. The syntax of the type string is:
where algorithm is one of:
- bf — Blowfish
- aes — AES (Rijndael-128)
and mode is one of:
- cbc — next block depends on previous (default)
- ecb — each block is encrypted separately (for testing only)
and padding is one of:
- pkcs — data may be any length (default)
- none — data must be multiple of cipher block size
So, for example, these are equivalent:
In
encrypt_iv
and decrypt_iv
, the iv parameter is the initial value for the CBC mode; it is ignored for ECB. It is clipped or padded with zeroes if not exactly block size. It defaults to all zeroes in the functions without this parameter.F.20.5. Random-data functions
Returns count cryptographically strong random bytes. At most 1024 bytes can be extracted at a time. This is to avoid draining the randomness generator pool.
F.20.6. Notes
F.20.6.1. Configuration
pgcrypto configures itself according to the findings of the main PostgreSQL configure script. The options that affect it are --with-zlib and --with-openssl.
When compiled with zlib, PGP encryption functions are able to compress data before encrypting.
When compiled with OpenSSL, there will be more algorithms available. Also public-key encryption functions will be faster as OpenSSL has more optimized BIGNUM functions.
Table F-21. Summary of functionality with and without OpenSSL
Functionality | Built-in | With OpenSSL |
---|---|---|
MD5 | yes | yes |
SHA1 | yes | yes |
SHA224/256/384/512 | yes | yes (Note 1) |
Other digest algorithms | no | yes (Note 2) |
Blowfish | yes | yes |
AES | yes | yes (Note 3) |
DES/3DES/CAST5 | no | yes |
Raw encryption | yes | yes |
PGP Symmetric encryption | yes | yes |
PGP Public-Key encryption | yes | yes |
Notes:
- SHA2 algorithms were added to OpenSSL in version 0.9.8. For older versions, pgcrypto will use built-in code.
- Any digest algorithm OpenSSL supports is automatically picked up. This is not possible with ciphers, which need to be supported explicitly.
- AES is included in OpenSSL since version 0.9.7. For older versions, pgcrypto will use built-in code.
F.20.6.2. NULL handling
As is standard in SQL, all functions return NULL, if any of the arguments are NULL. This may create security risks on careless usage.
F.20.6.3. Security limitations
All pgcrypto functions run inside the database server. That means that all the data and passwords move between pgcrypto and client applications in clear text. Thus you must:
- Connect locally or use SSL connections.
- Trust both system and database administrator.
If you cannot, then better do crypto inside client application.
F.20.6.4. Useful reading
- The GNU Privacy Handbook.
- Describes the crypt-blowfish algorithm.
- How to choose a good password.
- Interesting idea for picking passwords.
- Describes good and bad cryptography.
F.20.6.5. Technical references
- OpenPGP message format.
- The MD5 Message-Digest Algorithm.
- HMAC: Keyed-Hashing for Message Authentication.
- Comparison of crypt-des, crypt-md5 and bcrypt algorithms.
- Standards for DES, 3DES and AES.
- Description of Fortuna CSPRNG.
- Jean-Luc Cooke Fortuna-based /dev/random driver for Linux.
- Collection of cryptology pointers.
F.20.7. Author
Marko Kreen
<[email protected]>
pgcrypto uses code from the following sources:
Table F-22. Credits
Algorithm | Author | Source origin |
---|---|---|
DES crypt | David Burren and others | FreeBSD libcrypt |
MD5 crypt | Poul-Henning Kamp | FreeBSD libcrypt |
Blowfish crypt | Solar Designer | www.openwall.com |
Blowfish cipher | Simon Tatham | PuTTY |
Rijndael cipher | Brian Gladman | OpenBSD sys/crypto |
MD5 and SHA1 | WIDE Project | KAME kame/sys/crypto |
SHA256/384/512 | Aaron D. Gifford | OpenBSD sys/crypto |
BIGNUM math | Michael J. Fromberger | dartmouth.edu/~sting/sw/imath |
05-07-2012, 04:22 PM
Hello,
been trying for a few days now trying to get hashcat to work, cracking a MD5 hash with salt.
This is just a quick example or what I am trying to do
69c12c189531e95fc6b6b4191ce29220 is the hash
the salt is dz
the password for this is dz0000
fakehash has the above hash
salt has the above salt
This does not work:
./hashcat-cli32.bin -m 0 -a 3 -e salt --bf-pw-min=4 --bf-pw-max=6 --bf-cs-buf=1234567890 fakehash
When I run this it does work:
./hashcat-cli32.bin -m 0 -a 3 -e salt --bf-pw-min=4 --bf-pw-max=6 --bf-cs-buf=1234567890dz fakehash
When I run this it works but tries
./hashcat-cli32.bin -m 0 -a 3 -e salt --bf-pw-min=5 --bf-pw-max=6 --bf-cs-buf=abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ fackhash
to my understanding it start 0000 and goes from there so it should put dz in front and then at 6 it should do dz0000 resulting in the first crack. But instead it does 000000 and goes from there not using the salt. How do I force it to use salt any help would be greatly apprenticed.
been trying for a few days now trying to get hashcat to work, cracking a MD5 hash with salt.
This is just a quick example or what I am trying to do
69c12c189531e95fc6b6b4191ce29220 is the hash
the salt is dz
the password for this is dz0000
fakehash has the above hash
salt has the above salt
This does not work:
./hashcat-cli32.bin -m 0 -a 3 -e salt --bf-pw-min=4 --bf-pw-max=6 --bf-cs-buf=1234567890 fakehash
When I run this it does work:
./hashcat-cli32.bin -m 0 -a 3 -e salt --bf-pw-min=4 --bf-pw-max=6 --bf-cs-buf=1234567890dz fakehash
When I run this it works but tries
./hashcat-cli32.bin -m 0 -a 3 -e salt --bf-pw-min=5 --bf-pw-max=6 --bf-cs-buf=abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ fackhash
to my understanding it start 0000 and goes from there so it should put dz in front and then at 6 it should do dz0000 resulting in the first crack. But instead it does 000000 and goes from there not using the salt. How do I force it to use salt any help would be greatly apprenticed.