12 Commits (abecf1afc206e1f46d9202c7ba2122f06a799f8d)

Author	SHA1	Message	Date
Tom Lane	24ce1438c0	pgcrypto documentation update. Marko Kreen	21 years ago
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	21 years ago
Neil Conway	39e54e3208	Fix typos in documentation.	21 years ago
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	21 years ago
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	21 years ago
Bruce Momjian	9588084263	* regression tests ... * minor doc updates Marko Kreen	25 years ago
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	25 years ago
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	25 years ago
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	25 years ago
Tom Lane	10a4e0c2eb	Documentation update from Marko Kreen.	25 years ago
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	25 years ago
Peter Eisentraut	0c0dde6176	Hashing functions from Marko Kreen <marko@l-t.ee>	26 years ago