postgresql/contrib/pgcrypto/px.c

442 lines
9.2 KiB
C
Raw Normal View History

2001-08-21 09:32:01 +08:00
/*
* px.c
* Various cryptographic stuff for PostgreSQL.
*
2001-08-21 09:32:01 +08:00
* Copyright (c) 2001 Marko Kreen
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
2001-08-21 09:32:01 +08:00
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
2001-08-21 09:32:01 +08:00
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
2001-08-21 09:32:01 +08:00
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $PostgreSQL: pgsql/contrib/pgcrypto/px.c,v 1.18 2009/06/11 14:48:52 momjian Exp $
2001-08-21 09:32:01 +08:00
*/
#include "postgres.h"
2001-08-21 09:32:01 +08:00
#include "px.h"
2005-10-15 10:49:52 +08:00
struct error_desc
{
int err;
const char *desc;
};
static const struct error_desc px_err_list[] = {
{PXE_OK, "Everything ok"},
{PXE_ERR_GENERIC, "Some PX error (not specified)"},
{PXE_NO_HASH, "No such hash algorithm"},
{PXE_NO_CIPHER, "No such cipher algorithm"},
{PXE_NOTBLOCKSIZE, "Data not a multiple of block size"},
{PXE_BAD_OPTION, "Unknown option"},
{PXE_BAD_FORMAT, "Badly formatted type"},
{PXE_KEY_TOO_BIG, "Key was too big"},
{PXE_CIPHER_INIT, "Cipher cannot be initalized ?"},
{PXE_HASH_UNUSABLE_FOR_HMAC, "This hash algorithm is unusable for HMAC"},
{PXE_DEV_READ_ERROR, "Error reading from random device"},
{PXE_OSSL_RAND_ERROR, "OpenSSL PRNG error"},
{PXE_BUG, "pgcrypto bug"},
{PXE_ARGUMENT_ERROR, "Illegal argument to function"},
{PXE_UNKNOWN_SALT_ALGO, "Unknown salt algorithm"},
{PXE_BAD_SALT_ROUNDS, "Incorrect number of rounds"},
{PXE_MCRYPT_INTERNAL, "mcrypt internal error"},
{PXE_NO_RANDOM, "No strong random source"},
{PXE_DECRYPT_FAILED, "Decryption failed"},
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 11:57:55 +08:00
{PXE_PGP_CORRUPT_DATA, "Wrong key or corrupt data"},
{PXE_PGP_CORRUPT_ARMOR, "Corrupt ascii-armor"},
{PXE_PGP_UNSUPPORTED_COMPR, "Unsupported compression algorithm"},
{PXE_PGP_UNSUPPORTED_CIPHER, "Unsupported cipher algorithm"},
{PXE_PGP_UNSUPPORTED_HASH, "Unsupported digest algorithm"},
{PXE_PGP_COMPRESSION_ERROR, "Compression error"},
{PXE_PGP_NOT_TEXT, "Not text data"},
{PXE_PGP_UNEXPECTED_PKT, "Unexpected packet in key data"},
{PXE_PGP_NO_BIGNUM,
"public-key functions disabled - "
2005-10-15 10:49:52 +08:00
"pgcrypto needs OpenSSL for bignums"},
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 11:57:55 +08:00
{PXE_PGP_MATH_FAILED, "Math operation failed"},
{PXE_PGP_SHORT_ELGAMAL_KEY, "Elgamal keys must be at least 1024 bits long"},
{PXE_PGP_RSA_UNSUPPORTED, "pgcrypto does not support RSA keys"},
{PXE_PGP_UNKNOWN_PUBALGO, "Unknown public-key encryption algorithm"},
The large one adds support for RSA keys and reorganizes the pubkey functions a bit. The actual RSA-specific code there is tiny, most of the patch consists of reorg of the pubkey code, as lots of it was written as elgamal-only. --------------------------------------------------------------------------- The SHLIB section was copy-pasted from somewhere and contains several unnecessary libs. This cleans it up a bit. -lcrypt we don't use system crypt() -lssl, -lssleay32 no SSL here -lz in win32 section already added on previous line -ldes The chance anybody has it is pretty low. And the chance pgcrypto works with it is even lower. Also trim the win32 section. --------------------------------------------------------------------------- It is already disabled in Makefile, remove code too. --------------------------------------------------------------------------- I was bit hasty making the random exponent 'k' a prime. Further researh shows that Elgamal encryption has no specific needs in respect to k, any random number is fine. It is bit different for signing, there it needs to be 'relatively prime' to p - 1, that means GCD(k, p-1) == 1, which is also a lot lighter than full primality. As we don't do signing, this can be ignored. This brings major speedup to Elgamal encryption. --------------------------------------------------------------------------- o pgp_mpi_free: Accept NULLs o pgp_mpi_cksum: result should be 16bit o Remove function name from error messages - to be similar to other SQL functions, and it does not match anyway the called function o remove couple junk lines --------------------------------------------------------------------------- o Support for RSA encryption o Big reorg to better separate generic and algorithm-specific code. o Regression tests for RSA. --------------------------------------------------------------------------- o Tom stuck a CVS id into file. I doubt the usefulness of it, but if it needs to be in the file then rather at the end. Also tag it as comment for asciidoc. o Mention bytea vs. text difference o Couple clarifications --------------------------------------------------------------------------- There is a choice whether to update it with pgp functions or remove it. I decided to remove it, updating is pointless. I've tried to keep the core of pgcrypto relatively independent from main PostgreSQL, to make it easy to use externally if needed, and that is good. Eg. that made development of PGP functions much nicer. But I have no plans to release it as generic library, so keeping such doc up-to-date is waste of time. If anyone is interested in using it in other products, he can probably bother to read the source too. Commented source is another thing - I'll try to make another pass over code to see if there is anything non-obvious that would need more comments. --------------------------------------------------------------------------- Marko Kreen
2005-08-13 10:06:21 +08:00
{PXE_PGP_WRONG_KEY, "Wrong key"},
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 11:57:55 +08:00
{PXE_PGP_MULTIPLE_KEYS,
2005-10-15 10:49:52 +08:00
"Several keys given - pgcrypto does not handle keyring"},
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 11:57:55 +08:00
{PXE_PGP_EXPECT_PUBLIC_KEY, "Refusing to encrypt with secret key"},
{PXE_PGP_EXPECT_SECRET_KEY, "Cannot decrypt with public key"},
{PXE_PGP_NOT_V4_KEYPKT, "Only V4 key packets are supported"},
{PXE_PGP_KEYPKT_CORRUPT, "Corrupt key packet"},
The large one adds support for RSA keys and reorganizes the pubkey functions a bit. The actual RSA-specific code there is tiny, most of the patch consists of reorg of the pubkey code, as lots of it was written as elgamal-only. --------------------------------------------------------------------------- The SHLIB section was copy-pasted from somewhere and contains several unnecessary libs. This cleans it up a bit. -lcrypt we don't use system crypt() -lssl, -lssleay32 no SSL here -lz in win32 section already added on previous line -ldes The chance anybody has it is pretty low. And the chance pgcrypto works with it is even lower. Also trim the win32 section. --------------------------------------------------------------------------- It is already disabled in Makefile, remove code too. --------------------------------------------------------------------------- I was bit hasty making the random exponent 'k' a prime. Further researh shows that Elgamal encryption has no specific needs in respect to k, any random number is fine. It is bit different for signing, there it needs to be 'relatively prime' to p - 1, that means GCD(k, p-1) == 1, which is also a lot lighter than full primality. As we don't do signing, this can be ignored. This brings major speedup to Elgamal encryption. --------------------------------------------------------------------------- o pgp_mpi_free: Accept NULLs o pgp_mpi_cksum: result should be 16bit o Remove function name from error messages - to be similar to other SQL functions, and it does not match anyway the called function o remove couple junk lines --------------------------------------------------------------------------- o Support for RSA encryption o Big reorg to better separate generic and algorithm-specific code. o Regression tests for RSA. --------------------------------------------------------------------------- o Tom stuck a CVS id into file. I doubt the usefulness of it, but if it needs to be in the file then rather at the end. Also tag it as comment for asciidoc. o Mention bytea vs. text difference o Couple clarifications --------------------------------------------------------------------------- There is a choice whether to update it with pgp functions or remove it. I decided to remove it, updating is pointless. I've tried to keep the core of pgcrypto relatively independent from main PostgreSQL, to make it easy to use externally if needed, and that is good. Eg. that made development of PGP functions much nicer. But I have no plans to release it as generic library, so keeping such doc up-to-date is waste of time. If anyone is interested in using it in other products, he can probably bother to read the source too. Commented source is another thing - I'll try to make another pass over code to see if there is anything non-obvious that would need more comments. --------------------------------------------------------------------------- Marko Kreen
2005-08-13 10:06:21 +08:00
{PXE_PGP_NO_USABLE_KEY, "No encryption key found"},
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 11:57:55 +08:00
{PXE_PGP_NEED_SECRET_PSW, "Need password for secret key"},
{PXE_PGP_BAD_S2K_MODE, "Bad S2K mode"},
{PXE_PGP_UNSUPPORTED_PUBALGO, "Unsupported public key algorithm"},
{PXE_PGP_MULTIPLE_SUBKEYS, "Several subkeys not supported"},
/* fake this as PXE_PGP_CORRUPT_DATA */
{PXE_MBUF_SHORT_READ, "Corrupt data"},
2005-10-15 10:49:52 +08:00
{0, NULL},
};
2005-10-15 10:49:52 +08:00
const char *
px_strerror(int err)
{
const struct error_desc *e;
2005-10-15 10:49:52 +08:00
for (e = px_err_list; e->desc; e++)
if (e->err == err)
return e->desc;
return "Bad error code";
}
2001-08-21 09:32:01 +08:00
const char *
px_resolve_alias(const PX_Alias *list, const char *name)
2001-08-21 09:32:01 +08:00
{
while (list->name)
{
if (pg_strcasecmp(list->alias, name) == 0)
2001-08-21 09:32:01 +08:00
return list->name;
list++;
}
return name;
}
2005-10-15 10:49:52 +08:00
static void (*debug_handler) (const char *) = NULL;
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 11:57:55 +08:00
2005-10-15 10:49:52 +08:00
void
px_set_debug_handler(void (*handler) (const char *))
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 11:57:55 +08:00
{
debug_handler = handler;
}
2005-10-15 10:49:52 +08:00
void
px_debug(const char *fmt,...)
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 11:57:55 +08:00
{
2005-10-15 10:49:52 +08:00
va_list ap;
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 11:57:55 +08:00
va_start(ap, fmt);
2005-10-15 10:49:52 +08:00
if (debug_handler)
{
char buf[512];
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 11:57:55 +08:00
vsnprintf(buf, sizeof(buf), fmt, ap);
debug_handler(buf);
}
va_end(ap);
}
2001-08-21 09:32:01 +08:00
/*
* combo - cipher + padding (+ checksum)
*/
static unsigned
combo_encrypt_len(PX_Combo *cx, unsigned dlen)
2001-08-21 09:32:01 +08:00
{
return dlen + 512;
}
static unsigned
combo_decrypt_len(PX_Combo *cx, unsigned dlen)
2001-08-21 09:32:01 +08:00
{
return dlen;
}
static int
combo_init(PX_Combo *cx, const uint8 *key, unsigned klen,
const uint8 *iv, unsigned ivlen)
2001-08-21 09:32:01 +08:00
{
int err;
unsigned bs,
ks,
ivs;
PX_Cipher *c = cx->cipher;
uint8 *ivbuf = NULL;
uint8 *keybuf;
2001-08-21 09:32:01 +08:00
bs = px_cipher_block_size(c);
ks = px_cipher_key_size(c);
ivs = px_cipher_iv_size(c);
if (ivs > 0)
{
2001-08-21 09:32:01 +08:00
ivbuf = px_alloc(ivs);
memset(ivbuf, 0, ivs);
if (ivlen > ivs)
memcpy(ivbuf, iv, ivs);
else
memcpy(ivbuf, iv, ivlen);
}
if (klen > ks)
klen = ks;
2001-08-21 09:32:01 +08:00
keybuf = px_alloc(ks);
memset(keybuf, 0, ks);
memcpy(keybuf, key, klen);
err = px_cipher_init(c, keybuf, klen, ivbuf);
if (ivbuf)
px_free(ivbuf);
px_free(keybuf);
2001-08-21 09:32:01 +08:00
return err;
}
static int
combo_encrypt(PX_Combo *cx, const uint8 *data, unsigned dlen,
uint8 *res, unsigned *rlen)
2001-08-21 09:32:01 +08:00
{
int err = 0;
uint8 *bbuf;
unsigned bs,
maxlen,
bpos,
i,
pad;
2001-08-21 09:32:01 +08:00
PX_Cipher *c = cx->cipher;
2001-08-21 09:32:01 +08:00
bbuf = NULL;
maxlen = *rlen;
bs = px_cipher_block_size(c);
2001-08-21 09:32:01 +08:00
/* encrypt */
if (bs > 1)
{
2001-08-21 09:32:01 +08:00
bbuf = px_alloc(bs * 4);
bpos = dlen % bs;
*rlen = dlen - bpos;
memcpy(bbuf, data + *rlen, bpos);
/* encrypt full-block data */
if (*rlen)
{
2001-08-21 09:32:01 +08:00
err = px_cipher_encrypt(c, data, *rlen, res);
if (err)
goto out;
}
2001-08-21 09:32:01 +08:00
/* bbuf has now bpos bytes of stuff */
if (cx->padding)
{
2001-08-21 09:32:01 +08:00
pad = bs - (bpos % bs);
for (i = 0; i < pad; i++)
bbuf[bpos++] = pad;
}
else if (bpos % bs)
{
2001-08-21 09:32:01 +08:00
/* ERROR? */
pad = bs - (bpos % bs);
for (i = 0; i < pad; i++)
bbuf[bpos++] = 0;
}
/* encrypt the rest - pad */
if (bpos)
{
2001-08-21 09:32:01 +08:00
err = px_cipher_encrypt(c, bbuf, bpos, res + *rlen);
*rlen += bpos;
}
}
else
{
2001-08-21 09:32:01 +08:00
/* stream cipher/mode - no pad needed */
err = px_cipher_encrypt(c, data, dlen, res);
if (err)
goto out;
*rlen = dlen;
}
out:
if (bbuf)
px_free(bbuf);
2001-08-21 09:32:01 +08:00
return err;
}
static int
combo_decrypt(PX_Combo *cx, const uint8 *data, unsigned dlen,
uint8 *res, unsigned *rlen)
2001-08-21 09:32:01 +08:00
{
unsigned bs,
i,
pad;
unsigned pad_ok;
2001-08-21 09:32:01 +08:00
PX_Cipher *c = cx->cipher;
2001-08-21 09:32:01 +08:00
/* decide whether zero-length input is allowed */
if (dlen == 0)
{
/* with padding, empty ciphertext is not allowed */
if (cx->padding)
return PXE_DECRYPT_FAILED;
2007-11-16 05:14:46 +08:00
/* without padding, report empty result */
*rlen = 0;
return 0;
}
2001-08-21 09:32:01 +08:00
bs = px_cipher_block_size(c);
if (bs > 1 && (dlen % bs) != 0)
2001-08-21 09:32:01 +08:00
goto block_error;
2001-08-21 09:32:01 +08:00
/* decrypt */
*rlen = dlen;
px_cipher_decrypt(c, data, dlen, res);
2001-08-21 09:32:01 +08:00
/* unpad */
if (bs > 1 && cx->padding)
{
2001-08-21 09:32:01 +08:00
pad = res[*rlen - 1];
pad_ok = 0;
if (pad > 0 && pad <= bs && pad <= *rlen)
{
2001-08-21 09:32:01 +08:00
pad_ok = 1;
for (i = *rlen - pad; i < *rlen; i++)
if (res[i] != pad)
{
2001-08-21 09:32:01 +08:00
pad_ok = 0;
break;
}
}
2001-08-21 09:32:01 +08:00
if (pad_ok)
*rlen -= pad;
}
return 0;
2001-08-21 09:32:01 +08:00
block_error:
return PXE_NOTBLOCKSIZE;
2001-08-21 09:32:01 +08:00
}
static void
combo_free(PX_Combo *cx)
2001-08-21 09:32:01 +08:00
{
if (cx->cipher)
px_cipher_free(cx->cipher);
memset(cx, 0, sizeof(*cx));
px_free(cx);
}
/* PARSER */
static int
2001-08-21 09:32:01 +08:00
parse_cipher_name(char *full, char **cipher, char **pad)
{
char *p,
*p2,
*q;
2001-08-21 09:32:01 +08:00
*cipher = full;
*pad = NULL;
2001-08-21 09:32:01 +08:00
p = strchr(full, '/');
if (p != NULL)
*p++ = 0;
while (p != NULL)
{
2001-08-21 09:32:01 +08:00
if ((q = strchr(p, '/')) != NULL)
*q++ = 0;
if (!*p)
{
2001-08-21 09:32:01 +08:00
p = q;
continue;
}
p2 = strchr(p, ':');
if (p2 != NULL)
{
2001-08-21 09:32:01 +08:00
*p2++ = 0;
if (!strcmp(p, "pad"))
2001-08-21 09:32:01 +08:00
*pad = p2;
else
return PXE_BAD_OPTION;
}
else
return PXE_BAD_FORMAT;
2001-08-21 09:32:01 +08:00
p = q;
}
return 0;
2001-08-21 09:32:01 +08:00
}
/* provider */
int
px_find_combo(const char *name, PX_Combo **res)
2001-08-21 09:32:01 +08:00
{
int err;
char *buf,
*s_cipher,
*s_pad;
2001-08-21 09:32:01 +08:00
PX_Combo *cx;
2001-08-21 09:32:01 +08:00
cx = px_alloc(sizeof(*cx));
memset(cx, 0, sizeof(*cx));
buf = px_alloc(strlen(name) + 1);
strcpy(buf, name);
err = parse_cipher_name(buf, &s_cipher, &s_pad);
if (err)
{
2001-08-21 09:32:01 +08:00
px_free(buf);
px_free(cx);
return err;
2001-08-21 09:32:01 +08:00
}
err = px_find_cipher(s_cipher, &cx->cipher);
if (err)
goto err1;
if (s_pad != NULL)
{
2001-08-21 09:32:01 +08:00
if (!strcmp(s_pad, "pkcs"))
cx->padding = 1;
else if (!strcmp(s_pad, "none"))
cx->padding = 0;
else
goto err1;
}
else
2001-08-21 09:32:01 +08:00
cx->padding = 1;
cx->init = combo_init;
cx->encrypt = combo_encrypt;
cx->decrypt = combo_decrypt;
cx->encrypt_len = combo_encrypt_len;
cx->decrypt_len = combo_decrypt_len;
cx->free = combo_free;
px_free(buf);
*res = cx;
return 0;
2001-08-21 09:32:01 +08:00
err1:
if (cx->cipher)
px_cipher_free(cx->cipher);
px_free(cx);
px_free(buf);
return PXE_NO_CIPHER;
2001-08-21 09:32:01 +08:00
}