postgresql/contrib/pgcrypto/pgcrypto.sql.in

203 lines
5.1 KiB
MySQL
Raw Normal View History

/* $PostgreSQL: pgsql/contrib/pgcrypto/pgcrypto.sql.in,v 1.16 2010/08/19 05:57:33 petere Exp $ */
-- Adjust this setting to control where the objects get created.
SET search_path = public;
CREATE OR REPLACE FUNCTION digest(text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_digest'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION digest(bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_digest'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION hmac(text, text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_hmac'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION hmac(bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_hmac'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION crypt(text, text)
RETURNS text
AS 'MODULE_PATHNAME', 'pg_crypt'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION gen_salt(text)
RETURNS text
AS 'MODULE_PATHNAME', 'pg_gen_salt'
LANGUAGE C VOLATILE STRICT;
CREATE OR REPLACE FUNCTION gen_salt(text, int4)
RETURNS text
AS 'MODULE_PATHNAME', 'pg_gen_salt_rounds'
LANGUAGE C VOLATILE STRICT;
CREATE OR REPLACE FUNCTION encrypt(bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_encrypt'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION decrypt(bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_decrypt'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION encrypt_iv(bytea, bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_encrypt_iv'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION decrypt_iv(bytea, bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_decrypt_iv'
LANGUAGE C IMMUTABLE STRICT;
CREATE OR REPLACE FUNCTION gen_random_bytes(int4)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_random_bytes'
LANGUAGE 'C' VOLATILE STRICT;
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 05:57:55 +02:00
--
-- pgp_sym_encrypt(data, key)
--
CREATE OR REPLACE FUNCTION pgp_sym_encrypt(text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_sym_encrypt_text'
LANGUAGE C STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_sym_encrypt_bytea(bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_sym_encrypt_bytea'
LANGUAGE C STRICT;
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 05:57:55 +02:00
--
-- pgp_sym_encrypt(data, key, args)
--
CREATE OR REPLACE FUNCTION pgp_sym_encrypt(text, text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_sym_encrypt_text'
LANGUAGE C STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_sym_encrypt_bytea(bytea, text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_sym_encrypt_bytea'
LANGUAGE C STRICT;
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 05:57:55 +02:00
--
-- pgp_sym_decrypt(data, key)
--
CREATE OR REPLACE FUNCTION pgp_sym_decrypt(bytea, text)
RETURNS text
AS 'MODULE_PATHNAME', 'pgp_sym_decrypt_text'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_sym_decrypt_bytea(bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_sym_decrypt_bytea'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
--
-- pgp_sym_decrypt(data, key, args)
--
CREATE OR REPLACE FUNCTION pgp_sym_decrypt(bytea, text, text)
RETURNS text
AS 'MODULE_PATHNAME', 'pgp_sym_decrypt_text'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_sym_decrypt_bytea(bytea, text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_sym_decrypt_bytea'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
--
-- pgp_pub_encrypt(data, key)
--
CREATE OR REPLACE FUNCTION pgp_pub_encrypt(text, bytea)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_encrypt_text'
LANGUAGE C STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_pub_encrypt_bytea(bytea, bytea)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_encrypt_bytea'
LANGUAGE C STRICT;
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 05:57:55 +02:00
--
-- pgp_pub_encrypt(data, key, args)
--
CREATE OR REPLACE FUNCTION pgp_pub_encrypt(text, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_encrypt_text'
LANGUAGE C STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_pub_encrypt_bytea(bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_encrypt_bytea'
LANGUAGE C STRICT;
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 05:57:55 +02:00
--
-- pgp_pub_decrypt(data, key)
--
CREATE OR REPLACE FUNCTION pgp_pub_decrypt(bytea, bytea)
RETURNS text
AS 'MODULE_PATHNAME', 'pgp_pub_decrypt_text'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_pub_decrypt_bytea(bytea, bytea)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_decrypt_bytea'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
--
-- pgp_pub_decrypt(data, key, psw)
--
CREATE OR REPLACE FUNCTION pgp_pub_decrypt(bytea, bytea, text)
RETURNS text
AS 'MODULE_PATHNAME', 'pgp_pub_decrypt_text'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_pub_decrypt_bytea(bytea, bytea, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_decrypt_bytea'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
--
-- pgp_pub_decrypt(data, key, psw, arg)
--
CREATE OR REPLACE FUNCTION pgp_pub_decrypt(bytea, bytea, text, text)
RETURNS text
AS 'MODULE_PATHNAME', 'pgp_pub_decrypt_text'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION pgp_pub_decrypt_bytea(bytea, bytea, text, text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pgp_pub_decrypt_bytea'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
--
-- PGP key ID
--
CREATE OR REPLACE FUNCTION pgp_key_id(bytea)
RETURNS text
AS 'MODULE_PATHNAME', 'pgp_key_id_w'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
--
-- pgp armor
--
CREATE OR REPLACE FUNCTION armor(bytea)
RETURNS text
AS 'MODULE_PATHNAME', 'pg_armor'
LANGUAGE C IMMUTABLE STRICT;
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 05:57:55 +02:00
CREATE OR REPLACE FUNCTION dearmor(text)
RETURNS bytea
AS 'MODULE_PATHNAME', 'pg_dearmor'
LANGUAGE C IMMUTABLE STRICT;