mirror of
https://github.com/postgres/postgres.git
synced 2025-07-27 12:41:57 +03: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
This commit is contained in:
Bruce Momjian
@ -11,10 +11,10 @@ Edit makefile, if you want to use any external library.
|
||||
|
||||
NB! Default randomness source is libc random() function. This
|
||||
is so only to get pgcrypto build everywhere. Randomness is
|
||||
needed for gen_salt() function. So if you plan using it, you
|
||||
should definitely change that by editing Makefile. You should
|
||||
be using urandom device if your OS supports it, otherwise link
|
||||
pgcrypto against OpenSSL library and use its PRNG.
|
||||
needed for gen_salt() and pgp_encrypt() functions. So if you plan
|
||||
using those, you should definitely change that by editing Makefile.
|
||||
You can should use urandom device if your OS supports it, otherwise
|
||||
link pgcrypto against OpenSSL library and use its PRNG.
|
||||
|
||||
After editing Makefile:
|
||||
|
||||
@ -108,6 +108,161 @@ gen_salt(type::text, rounds::int4)::text
|
||||
For maximum security, you should choose the 'bf' crypt
|
||||
and use maximum number of rounds you can still tolerate.
|
||||
|
||||
armor(bytea)::text
|
||||
dearmor(text)::bytea
|
||||
|
||||
Those wrap/unwrap data into PGP Ascii Armor which
|
||||
is basically Base64 with CRC and additional formatting.
|
||||
|
||||
pgp_sym_encrypt(data::text, key::text)::bytea
|
||||
pgp_sym_encrypt(data::text, key::text, arg::text)::bytea
|
||||
pgp_sym_encrypt_bytea(data::bytea, key::text)::bytea
|
||||
pgp_sym_encrypt_bytea(data::bytea, key::text, arg::text)::bytea
|
||||
|
||||
pgp_sym_decrypt(data::bytea, key::text)::text
|
||||
pgp_sym_decrypt(data::bytea, key::text, arg::text)::text
|
||||
pgp_sym_decrypt_bytea(data::text, key::text)::bytea
|
||||
pgp_sym_decrypt_bytea(data::text, key::text, arg::text)::bytea
|
||||
|
||||
Encrypt data into OpenPGP Symmetrically Encrypted Data
|
||||
message. And decrypt it from it.
|
||||
|
||||
Note that the pgp_sym_encrypt_bytea functions tag the data
|
||||
as binary, as the pgp_sym_encrypt will tag the data as text.
|
||||
You can not decrypt the binary data as text. But you can
|
||||
decrypt text data as binary. This rule avoids having
|
||||
broken textual data in PostgreSQL.
|
||||
|
||||
Both encrypt and decrypt accept also third argument, which
|
||||
is parameters to the function in following format:
|
||||
|
||||
parm=val[,parm=val]...
|
||||
|
||||
Example:
|
||||
|
||||
select pgp_sym_encrypt('data', 'psw',
|
||||
'compress-algo=2, unicode-mode=1');
|
||||
|
||||
Accepted parameters are:
|
||||
|
||||
cipher-algo: bf, aes, aes128, aes192, aes256
|
||||
Cipher algorithm to use. OpenSSL gives additional algorithms:
|
||||
3des, cast5
|
||||
Default: aes128
|
||||
|
||||
compress-algo: 0, 1, 2
|
||||
Which compression algorithm to use.
|
||||
0 - no compression
|
||||
1 - ZIP compression
|
||||
2 - ZLIB compression [=ZIP plus meta-data and block-CRC's]
|
||||
Default: 0
|
||||
|
||||
compress-level: 0, 1-9
|
||||
How much to compress. Bigger level compresses smaller
|
||||
but also slower. 0 disables compression.
|
||||
Default: 6
|
||||
|
||||
convert-crlf: 0, 1
|
||||
Whether to convert \n into \r\n when encrypting and
|
||||
\r\n to \n when decrypting. RFC2440 specifies that
|
||||
text packets should use "\r\n" line-feeds.
|
||||
Use this to get fully RFC-compliant behaviour.
|
||||
Default: 0
|
||||
|
||||
disable-mdc: 0, 1
|
||||
Do not protect data with SHA-1. Note that SHA-1 protected
|
||||
packet is from upcoming update to RFC2440. (Currently at
|
||||
version RFC2440bis-13.) You need to disable it if you need
|
||||
compatibility with ancient PGP products. Recent gnupg.org
|
||||
and pgp.com software supports it fine.
|
||||
Default: 0
|
||||
|
||||
enable-session-key: 0, 1
|
||||
Use separate session key.
|
||||
Default: 0
|
||||
|
||||
s2k-mode: 0, 1, 3
|
||||
Which S2K algorithm to use. 0 is dangerous - without salt.
|
||||
Default: 3
|
||||
|
||||
s2k-digest-algo: md5, sha1
|
||||
Which digest algorithm to use in S2K calculation.
|
||||
Default: SHA-1
|
||||
|
||||
s2k-cipher-algo: bf, aes, aes128, aes192, aes256
|
||||
Which cipher to use for encrypting separate session key.
|
||||
Default: same as cipher-algo.
|
||||
|
||||
unicode-mode: 0, 1
|
||||
Whether to convert textual data from database internal
|
||||
encoding to UTF-8 and back.
|
||||
Default: 0
|
||||
|
||||
Only 'convert-crlf' applies to both encrypt and decrypt,
|
||||
all others apply only to encrypt - decrypt gets the
|
||||
settings from PGP data.
|
||||
|
||||
|
||||
pgp_pub_encrypt(data::text, key::bytea)::bytea
|
||||
pgp_pub_encrypt(data::text, key::bytea, arg::text)::bytea
|
||||
pgp_pub_encrypt_bytea(data::bytea, bytea::text)::bytea
|
||||
pgp_pub_encrypt_bytea(data::bytea, bytea::text, arg::text)::bytea
|
||||
|
||||
pgp_pub_decrypt(data::bytea, key::bytea)::text
|
||||
pgp_pub_decrypt(data::bytea, key::bytea, psw::text)::text
|
||||
pgp_pub_decrypt(data::bytea, key::bytea, psw::text, arg::text)::text
|
||||
pgp_pub_decrypt_bytea(data::text, key::bytea)::bytea
|
||||
pgp_pub_decrypt_bytea(data::text, key::bytea, psw::text)::bytea
|
||||
pgp_pub_decrypt_bytea(data::text, key::bytea, psw::text, arg::bytea)::bytea
|
||||
|
||||
Encrypt data into OpenPGP Public-Key Encrypted Data
|
||||
message. And decrypt it from it. The arg parameter is
|
||||
described in pgp_sym_* section.
|
||||
|
||||
The key must be a public-key packet for pgp_pub_encrypt
|
||||
functions and a secret key packet for pgp_pub_decrypt
|
||||
functions. Trying to encrypt with secret key gives a error.
|
||||
While being technically possible, it is probably a sign of
|
||||
user error and leaking secret keys.
|
||||
|
||||
Here is a example how to generate them:
|
||||
|
||||
Generate a new key:
|
||||
|
||||
gpg --gen-key
|
||||
|
||||
You need to pick "DSA and Elgamal" key type, others
|
||||
are sign-only.
|
||||
|
||||
List keys:
|
||||
|
||||
gpg --list-secret-keys
|
||||
|
||||
Export ascii-armored public key:
|
||||
|
||||
gpg -a --export KEYID > public.key
|
||||
|
||||
Export ascii-armored secret key:
|
||||
|
||||
gpg -a --export-secret-keys KEYID > secret.key
|
||||
|
||||
You need to use dearmor() on them before giving giving
|
||||
them to pgp_pub_* functions. Ofcourse, if you can handle
|
||||
binary data, you can drop "-a" from gpg.
|
||||
|
||||
|
||||
pgp_key_id(key / data)
|
||||
|
||||
It shows you either key ID if given PGP public or secret
|
||||
key. Or it gives the key ID what was used for encrypting
|
||||
the data, if given encrypted data.
|
||||
|
||||
It can return 2 special key ID's:
|
||||
|
||||
SYMKEY - it got symmetrically encrypted data.
|
||||
ANYKEY - the data packet key ID is clear. That means
|
||||
you should try all you secret keys on it.
|
||||
|
||||
encrypt(data::bytea, key::bytea, type::text)::bytea
|
||||
decrypt(data::bytea, key::bytea, type::text)::bytea
|
||||
encrypt_iv(data::bytea, key::bytea, iv::bytea, type::text)::bytea
|
||||
|
||||
Reference in New Issue
Block a user