2001-08-21 03:32:01 +02:00
|
|
|
/*
|
|
|
|
* px.h
|
|
|
|
* Header file for pgcrypto.
|
2001-10-25 07:50:21 +02:00
|
|
|
*
|
2001-08-21 03:32:01 +02: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
|
2001-10-25 07:50:21 +02:00
|
|
|
* notice, this list of conditions and the following disclaimer.
|
2001-08-21 03:32:01 +02:00
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
2001-10-25 07:50:21 +02:00
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
2001-08-21 03:32:01 +02: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
|
2014-05-06 18:12:18 +02:00
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
2001-08-21 03:32:01 +02: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.
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* contrib/pgcrypto/px.h
|
2001-08-21 03:32:01 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __PX_H
|
|
|
|
#define __PX_H
|
|
|
|
|
2002-10-21 20:56:30 +02:00
|
|
|
#include <sys/param.h>
|
2001-11-29 20:40:37 +01:00
|
|
|
|
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
|
|
|
/* keep debug messages? */
|
|
|
|
#define PX_DEBUG
|
2001-11-29 20:40:37 +01:00
|
|
|
|
2001-08-21 03:32:01 +02:00
|
|
|
/* max salt returned */
|
|
|
|
#define PX_MAX_SALT_LEN 128
|
|
|
|
|
2005-03-21 06:19:55 +01:00
|
|
|
/*
|
|
|
|
* PX error codes
|
|
|
|
*/
|
|
|
|
#define PXE_OK 0
|
|
|
|
#define PXE_ERR_GENERIC -1
|
|
|
|
#define PXE_NO_HASH -2
|
|
|
|
#define PXE_NO_CIPHER -3
|
2022-03-22 08:51:05 +01:00
|
|
|
/* -4 is unused */
|
2005-03-21 06:19:55 +01:00
|
|
|
#define PXE_BAD_OPTION -5
|
|
|
|
#define PXE_BAD_FORMAT -6
|
|
|
|
#define PXE_KEY_TOO_BIG -7
|
|
|
|
#define PXE_CIPHER_INIT -8
|
|
|
|
#define PXE_HASH_UNUSABLE_FOR_HMAC -9
|
2022-02-21 10:55:03 +01:00
|
|
|
/* -10 is unused */
|
|
|
|
/* -11 is unused */
|
2005-03-21 06:19:55 +01:00
|
|
|
#define PXE_BUG -12
|
|
|
|
#define PXE_ARGUMENT_ERROR -13
|
|
|
|
#define PXE_UNKNOWN_SALT_ALGO -14
|
|
|
|
#define PXE_BAD_SALT_ROUNDS -15
|
2022-02-21 10:28:43 +01:00
|
|
|
/* -16 is unused */
|
2005-03-21 06:22:14 +01:00
|
|
|
#define PXE_NO_RANDOM -17
|
2007-08-23 18:15:51 +02:00
|
|
|
#define PXE_DECRYPT_FAILED -18
|
2020-11-01 11:22:59 +01:00
|
|
|
#define PXE_ENCRYPT_FAILED -19
|
2001-08-21 03:32:01 +02:00
|
|
|
|
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
|
|
|
#define PXE_PGP_CORRUPT_DATA -100
|
|
|
|
#define PXE_PGP_CORRUPT_ARMOR -101
|
2005-10-15 04:49:52 +02:00
|
|
|
#define PXE_PGP_UNSUPPORTED_COMPR -102
|
|
|
|
#define PXE_PGP_UNSUPPORTED_CIPHER -103
|
|
|
|
#define PXE_PGP_UNSUPPORTED_HASH -104
|
|
|
|
#define PXE_PGP_COMPRESSION_ERROR -105
|
|
|
|
#define PXE_PGP_NOT_TEXT -106
|
|
|
|
#define PXE_PGP_UNEXPECTED_PKT -107
|
2016-11-30 12:04:16 +01:00
|
|
|
/* -108 is unused */
|
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
|
|
|
#define PXE_PGP_MATH_FAILED -109
|
|
|
|
#define PXE_PGP_SHORT_ELGAMAL_KEY -110
|
2016-11-30 12:04:16 +01:00
|
|
|
/* -111 is unused */
|
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
|
|
|
#define PXE_PGP_UNKNOWN_PUBALGO -112
|
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 04:06:21 +02:00
|
|
|
#define PXE_PGP_WRONG_KEY -113
|
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
|
|
|
#define PXE_PGP_MULTIPLE_KEYS -114
|
|
|
|
#define PXE_PGP_EXPECT_PUBLIC_KEY -115
|
|
|
|
#define PXE_PGP_EXPECT_SECRET_KEY -116
|
|
|
|
#define PXE_PGP_NOT_V4_KEYPKT -117
|
|
|
|
#define PXE_PGP_KEYPKT_CORRUPT -118
|
|
|
|
#define PXE_PGP_NO_USABLE_KEY -119
|
|
|
|
#define PXE_PGP_NEED_SECRET_PSW -120
|
|
|
|
#define PXE_PGP_BAD_S2K_MODE -121
|
2005-10-15 04:49:52 +02:00
|
|
|
#define PXE_PGP_UNSUPPORTED_PUBALGO -122
|
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
|
|
|
#define PXE_PGP_MULTIPLE_SUBKEYS -123
|
|
|
|
|
|
|
|
|
2001-08-21 03:32:01 +02:00
|
|
|
typedef struct px_digest PX_MD;
|
|
|
|
typedef struct px_alias PX_Alias;
|
|
|
|
typedef struct px_hmac PX_HMAC;
|
|
|
|
typedef struct px_cipher PX_Cipher;
|
|
|
|
typedef struct px_combo PX_Combo;
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
struct px_digest
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
unsigned (*result_size) (PX_MD *h);
|
|
|
|
unsigned (*block_size) (PX_MD *h);
|
|
|
|
void (*reset) (PX_MD *h);
|
|
|
|
void (*update) (PX_MD *h, const uint8 *data, unsigned dlen);
|
|
|
|
void (*finish) (PX_MD *h, uint8 *dst);
|
|
|
|
void (*free) (PX_MD *h);
|
2001-08-21 03:32:01 +02:00
|
|
|
/* private */
|
2001-10-25 07:50:21 +02:00
|
|
|
union
|
|
|
|
{
|
2001-11-20 16:50:53 +01:00
|
|
|
unsigned code;
|
2005-10-15 04:49:52 +02:00
|
|
|
void *ptr;
|
2001-10-25 07:50:21 +02:00
|
|
|
} p;
|
2001-08-21 03:32:01 +02:00
|
|
|
};
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
struct px_alias
|
|
|
|
{
|
|
|
|
char *alias;
|
|
|
|
char *name;
|
2001-08-21 03:32:01 +02:00
|
|
|
};
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
struct px_hmac
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
unsigned (*result_size) (PX_HMAC *h);
|
|
|
|
unsigned (*block_size) (PX_HMAC *h);
|
|
|
|
void (*reset) (PX_HMAC *h);
|
|
|
|
void (*update) (PX_HMAC *h, const uint8 *data, unsigned dlen);
|
|
|
|
void (*finish) (PX_HMAC *h, uint8 *dst);
|
|
|
|
void (*free) (PX_HMAC *h);
|
|
|
|
void (*init) (PX_HMAC *h, const uint8 *key, unsigned klen);
|
2001-10-25 07:50:21 +02:00
|
|
|
|
|
|
|
PX_MD *md;
|
2001-08-21 03:32:01 +02:00
|
|
|
/* private */
|
2001-10-25 07:50:21 +02:00
|
|
|
struct
|
|
|
|
{
|
|
|
|
uint8 *ipad;
|
|
|
|
uint8 *opad;
|
|
|
|
} p;
|
2001-08-21 03:32:01 +02:00
|
|
|
};
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
struct px_cipher
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
unsigned (*block_size) (PX_Cipher *c);
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
unsigned (*key_size) (PX_Cipher *c); /* max key len */
|
2009-06-11 16:49:15 +02:00
|
|
|
unsigned (*iv_size) (PX_Cipher *c);
|
|
|
|
|
|
|
|
int (*init) (PX_Cipher *c, const uint8 *key, unsigned klen, const uint8 *iv);
|
2022-03-22 08:51:05 +01:00
|
|
|
int (*encrypt) (PX_Cipher *c, int padding, const uint8 *data, unsigned dlen, uint8 *res, unsigned *rlen);
|
|
|
|
int (*decrypt) (PX_Cipher *c, int padding, const uint8 *data, unsigned dlen, uint8 *res, unsigned *rlen);
|
2009-06-11 16:49:15 +02:00
|
|
|
void (*free) (PX_Cipher *c);
|
2001-08-21 03:32:01 +02:00
|
|
|
/* private */
|
2001-10-25 07:50:21 +02:00
|
|
|
void *ptr;
|
|
|
|
int pstat; /* mcrypt uses it */
|
2001-08-21 03:32:01 +02:00
|
|
|
};
|
|
|
|
|
2001-10-25 07:50:21 +02:00
|
|
|
struct px_combo
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
int (*init) (PX_Combo *cx, const uint8 *key, unsigned klen,
|
2017-06-21 20:39:04 +02:00
|
|
|
const uint8 *iv, unsigned ivlen);
|
2009-06-11 16:49:15 +02:00
|
|
|
int (*encrypt) (PX_Combo *cx, const uint8 *data, unsigned dlen,
|
2017-06-21 20:39:04 +02:00
|
|
|
uint8 *res, unsigned *rlen);
|
2009-06-11 16:49:15 +02:00
|
|
|
int (*decrypt) (PX_Combo *cx, const uint8 *data, unsigned dlen,
|
2017-06-21 20:39:04 +02:00
|
|
|
uint8 *res, unsigned *rlen);
|
2009-06-11 16:49:15 +02:00
|
|
|
unsigned (*encrypt_len) (PX_Combo *cx, unsigned dlen);
|
|
|
|
unsigned (*decrypt_len) (PX_Combo *cx, unsigned dlen);
|
|
|
|
void (*free) (PX_Combo *cx);
|
2001-10-25 07:50:21 +02:00
|
|
|
|
|
|
|
PX_Cipher *cipher;
|
2001-11-20 16:50:53 +01:00
|
|
|
unsigned padding;
|
2001-08-21 03:32:01 +02:00
|
|
|
};
|
|
|
|
|
2009-06-11 16:49:15 +02:00
|
|
|
int px_find_digest(const char *name, PX_MD **res);
|
|
|
|
int px_find_hmac(const char *name, PX_HMAC **res);
|
|
|
|
int px_find_cipher(const char *name, PX_Cipher **res);
|
|
|
|
int px_find_combo(const char *name, PX_Combo **res);
|
2001-08-21 03:32:01 +02:00
|
|
|
|
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 12:42:59 +01:00
|
|
|
void px_THROW_ERROR(int err) pg_attribute_noreturn();
|
2005-03-21 06:19:55 +01:00
|
|
|
const char *px_strerror(int err);
|
|
|
|
|
2009-06-11 16:49:15 +02:00
|
|
|
const char *px_resolve_alias(const PX_Alias *aliases, const char *name);
|
2001-08-21 03:32:01 +02:00
|
|
|
|
2005-10-15 04:49:52 +02:00
|
|
|
void px_set_debug_handler(void (*handler) (const char *));
|
|
|
|
|
2014-04-17 18:37:53 +02:00
|
|
|
void px_memset(void *ptr, int c, size_t len);
|
|
|
|
|
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
|
|
|
#ifdef PX_DEBUG
|
2015-03-26 19:03:19 +01:00
|
|
|
void px_debug(const char *fmt,...) pg_attribute_printf(1, 2);
|
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
|
|
|
#else
|
|
|
|
#define px_debug(...)
|
|
|
|
#endif
|
|
|
|
|
2001-08-21 03:32:01 +02:00
|
|
|
#define px_md_result_size(md) (md)->result_size(md)
|
|
|
|
#define px_md_block_size(md) (md)->block_size(md)
|
|
|
|
#define px_md_reset(md) (md)->reset(md)
|
|
|
|
#define px_md_update(md, data, dlen) (md)->update(md, data, dlen)
|
|
|
|
#define px_md_finish(md, buf) (md)->finish(md, buf)
|
|
|
|
#define px_md_free(md) (md)->free(md)
|
|
|
|
|
|
|
|
#define px_hmac_result_size(hmac) (hmac)->result_size(hmac)
|
|
|
|
#define px_hmac_block_size(hmac) (hmac)->block_size(hmac)
|
|
|
|
#define px_hmac_reset(hmac) (hmac)->reset(hmac)
|
|
|
|
#define px_hmac_init(hmac, key, klen) (hmac)->init(hmac, key, klen)
|
|
|
|
#define px_hmac_update(hmac, data, dlen) (hmac)->update(hmac, data, dlen)
|
|
|
|
#define px_hmac_finish(hmac, buf) (hmac)->finish(hmac, buf)
|
|
|
|
#define px_hmac_free(hmac) (hmac)->free(hmac)
|
|
|
|
|
|
|
|
|
|
|
|
#define px_cipher_key_size(c) (c)->key_size(c)
|
|
|
|
#define px_cipher_block_size(c) (c)->block_size(c)
|
|
|
|
#define px_cipher_iv_size(c) (c)->iv_size(c)
|
|
|
|
#define px_cipher_init(c, k, klen, iv) (c)->init(c, k, klen, iv)
|
2022-03-22 08:51:05 +01:00
|
|
|
#define px_cipher_encrypt(c, padding, data, dlen, res, rlen) \
|
|
|
|
(c)->encrypt(c, padding, data, dlen, res, rlen)
|
|
|
|
#define px_cipher_decrypt(c, padding, data, dlen, res, rlen) \
|
|
|
|
(c)->decrypt(c, padding, data, dlen, res, rlen)
|
2001-08-21 03:32:01 +02:00
|
|
|
#define px_cipher_free(c) (c)->free(c)
|
|
|
|
|
|
|
|
|
|
|
|
#define px_combo_encrypt_len(c, dlen) (c)->encrypt_len(c, dlen)
|
|
|
|
#define px_combo_decrypt_len(c, dlen) (c)->decrypt_len(c, dlen)
|
|
|
|
#define px_combo_init(c, key, klen, iv, ivlen) \
|
|
|
|
(c)->init(c, key, klen, iv, ivlen)
|
|
|
|
#define px_combo_encrypt(c, data, dlen, res, rlen) \
|
|
|
|
(c)->encrypt(c, data, dlen, res, rlen)
|
|
|
|
#define px_combo_decrypt(c, data, dlen, res, rlen) \
|
|
|
|
(c)->decrypt(c, data, dlen, res, rlen)
|
|
|
|
#define px_combo_free(c) (c)->free(c)
|
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* __PX_H */
|