Commit Graph

12 Commits

Author SHA1 Message Date
Tom Lane
24ce1438c0 pgcrypto documentation update. Marko Kreen 2005-07-18 17:17:12 +00:00
Bruce Momjian
73e2431817 Major pgcrypto changes:
of password-based encryption from RFC2440 (OpenPGP).

The goal of this code is to be more featureful encryption solution
than current encrypt(), which only functionality is running cipher
over data.

Compared to encrypt(), pgp_encrypt() does following:

* It uses the equvialent of random Inital Vector to get cipher
  into random state before it processes user data
* Stores SHA-1 of the data into result so any modification
  will be detected.
* Remembers if data was text or binary - thus it can decrypt
  to/from text data.  This was a major nuisance for encrypt().
* Stores info about used algorithms with result, so user needs
  not remember them - more user friendly!
* Uses String2Key algorithms (similar to crypt()) with random salt
  to generate full-length binary key to be used for encrypting.
* Uses standard format for data - you can feed it to GnuPG, if needed.

Optional features (off by default):

* Can use separate session key - user data will be encrypted
  with totally random key, which will be encrypted with S2K
  generated key and attached to result.
* Data compression with zlib.
* Can convert between CRLF<->LF line-endings - to get fully
  RFC2440-compliant behaviour.  This is off by default as
  pgcrypto does not know the line-endings of user data.

Interface is simple:


    pgp_encrypt(data text, key text) returns bytea
    pgp_decrypt(data text, key text) returns text
    pgp_encrypt_bytea(data bytea, key text) returns bytea
    pgp_decrypt_bytea(data bytea, key text) returns bytea

To change parameters (cipher, compression, mdc):

    pgp_encrypt(data text, key text, parms text) returns bytea
    pgp_decrypt(data text, key text, parms text) returns text
    pgp_encrypt_bytea(data bytea, key text, parms text) returns bytea
    pgp_decrypt_bytea(data bytea, key text, parms text) returns bytea

Parameter names I lifted from gpg:

   pgp_encrypt('message', 'key', 'compress-algo=1,cipher-algo=aes256')

For text data, pgp_encrypt simply encrypts the PostgreSQL internal data.

This maps to RFC2440 data type 't' - 'extenally specified encoding'.
But this may cause problems if data is dumped and reloaded into database
which as different internal encoding.  My next goal is to implement data
type 'u' - which means data is in UTF-8 encoding by converting internal
encoding to UTF-8 and back.  And there wont be any compatibility
problems with current code, I think its ok to submit this without UTF-8
encoding by converting internal encoding to UTF-8 and back.  And there
wont be any compatibility problems with current code, I think its ok to
submit this without UTF-8 support.


Here is v4 of PGP encrypt.  This depends on previously sent
Fortuna-patch, as it uses the px_add_entropy function.

- New function: pgp_key_id() for finding key id's.
- Add SHA1 of user data and key into RNG pools.  We need to get
  randomness from somewhere, and it is in user best interests
  to contribute.
- Regenerate pgp-armor test for SQL_ASCII database.
- Cleanup the key handling so that the pubkey support is less
  hackish.

Marko Kreen
2005-07-10 03:57:55 +00:00
Neil Conway
39e54e3208 Fix typos in documentation. 2005-05-03 03:10:01 +00:00
Neil Conway
1ea9169b42 pgcrypto update:
* openssl.c: Add 3des and AES support
* README.pgcrypto: list only supported ciphers for openssl

OpenSSL has pre-processor symbol OPENSSL_NO_AES, which
isn't that helpful for detecting if it _does_ exist.
Thus the hack with AES_ENCRYPT.

Marko Kreen
2005-03-21 05:21:04 +00:00
Neil Conway
3cc8661232 Remove support for libmhash/libmcrypt.
libmcrypt seems to dead, maintainer address bounces,
and cast-128 fails on 2 of the 3 test vectors from RFC2144.

So I see no reason to keep around stuff I don't trust
anymore.

Support for several crypto libraries is probably only
confusing to users, although it was good for initial
developing - it helped to find hidden assumptions and
forced me to create regression tests for all functionality.

Marko Kreen
2005-03-21 05:17:16 +00:00
Bruce Momjian
9588084263 * regression tests
* minor doc updates

Marko Kreen
2001-09-30 22:18:29 +00:00
Bruce Momjian
cff23429d6 I noticed that the contrib Makefiles were reorganized.
Converted pgcrypto one too.

* Changed default randomness source to libc random()
  That way pgcrypto does not have any external dependencies
  and should work everywhere.
* Re-enabled pgcrypto build in contrib/makefile
* contrib/README update - there is more stuff than
  only 'hash functions'
* Noted the libc random fact in README.pgcrypto


Marko Kreen
2001-09-29 03:11:58 +00:00
Bruce Momjian
ab56022864 Big thanks to Solar Designer who pointed out a bug in bcrypt
salt generation code.  He also urged using better random source
and making possible to choose using bcrypt and xdes rounds more
easily.  So, here's patch:

* For all salt generation, use Solar Designer's own code.  This
  is mostly due fact that his code is more fit for get_random_bytes()
  style interface.
* New function: gen_salt(type, rounds).  This lets specify iteration
  count for algorithm.
* random.c: px_get_random_bytes() function.
  Supported randomness soure: /dev/urandom, OpenSSL PRNG, libc random()
  Default: /dev/urandom.
* Draft description of C API for pgcrypto functions.

New files: API, crypt-gensalt.c, random.c

Marko Kreen
2001-09-23 04:12:44 +00:00
Bruce Momjian
2518e27334 /contrib/pgcrypto:
* remove support for encode() as it is in main tree now
* remove krb5.c
* new 'PX library' architecture
* remove BSD license from my code to let the general
  PostgreSQL one to apply
* md5, sha1: ANSIfy, use const where appropriate
* various other formatting and clarity changes
* hmac()
* UN*X-like crypt() - system or internal crypt
* Internal crypt: DES, Extended DES, MD5, Blowfish
  crypt-des.c, crypt-md5.c from FreeBSD
  crypt-blowfish.c from Solar Designer
* gen_salt() for crypt() -  Blowfish, MD5, DES, Extended DES
* encrypt(), decrypt(), encrypt_iv(), decrypt_iv()
* Cipher support in mhash.c, openssl.c
* internal: Blowfish, Rijndael-128 ciphers
* blf.[ch], rijndael.[ch] from OpenBSD
* there will be generated file rijndael-tbl.inc.

Marko Kreen
2001-08-21 00:42:41 +00:00
Tom Lane
10a4e0c2eb Documentation update from Marko Kreen. 2001-03-16 17:42:56 +00:00
Bruce Momjian
cb5427ee47 I would like to do a interface change in pgcrypto. (Good
timing, I know :))  At the moment the digest() function returns
hexadecimal coded hash, but I want it to return pure binary.  I
have also included functions encode() and decode() which support
'base64' and 'hex' encodings, so if anyone needs digest() in hex
he can do encode(digest(...), 'hex').

Main reason for it is "to do one thing and do it well" :)

Another reason is if someone needs really lot of digesting, in
the end he wants to store the binary not the hexadecimal result.
It is really silly to convert it to hex then back to binary
again.  As I said if someone needs hex he can get it.

Well, and the real reason that I am doing encrypt()/decrypt()
functions and _they_ return binary.  For testing I like to see
it in hex occasionally, but it is really wrong to let them
return hex.  Only now it caught my eye that hex-coding in
digest() is wrong.  When doing digest() I thought about 'common
case' but hacking with psql is probably _not_ the common case :)

Marko Kreen
2001-01-24 03:46:16 +00:00
Peter Eisentraut
0c0dde6176 Hashing functions from Marko Kreen <marko@l-t.ee> 2000-10-31 13:11:28 +00:00