Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------


Marko Kreen wrote:
>
> Well, I needed to decide, whether it is realistic to implement
> PGP public-key encryption someday, because then I better rename
> the function 'pgp_encrypt' to something more specific immidiately.
>
> But after hacking a while, I soon had working implementation,
> so it seems silly to wait 8.2 for it. This is thanks to the
> fact that for encryption I can ignore most of the OpenPGP
> complex parts - signing and key-management. IMHO they don't
> even make sense inside database, they need an end-user
> application.
>
> In short, the goal of this code is not to be full OpenPGP
> implementation, but just provide more flexible encryption
> than the usual symmetric encryption.
>
> So here is updated pgp_encrypt patch, with support for both
> symmetric and public-key encryption. Also, as Neil requested,
> non-failing regression tests - unsupported parts are replaced
> with empty test named '*-DISABLED'.
>
> Note: it uses OpenSSL bignum code - so without OpenSSL
> no public-key encryption. Look below for plans for
> fixing this dependance.
>
> New names for symmetric-key functions:
>
> pgp_sym_encrypt(data, key)
> pgp_sym_decrypt(data, key)
>
> Public key functions:
>
> pgp_pub_encrypt(data, key)
> pgp_pub_decrypt(data, key)
> pgp_pub_decrypt(data, key, psw)
>
> Plus variants with 'arg' and for bytea.
>
> Not mentioned in previous mails:
>
> armor(bytea) -> text
> dearmor(text) -> bytea
>
> Apply and remove PGP Ascii Armor.
>
>
>
> Implemented feature?:
> * Elgamal-encryption keys - preferred public-key algo for OpenPGP.
> * Password-protected secret keys.
>
> Missing features (needs implementing ASAP):
> * pgp_key_id() - Function to query the ID of a key, and
> the key ID from encrypted packet - so user can implement
> key rings on his own.
>
> Maybe:
> * As it does not parse sign packets, it does not support
> recipient cipher preferences. It is not important for
> planned use-case, but maybe it would be nice to have.
>
> Does not support (and I see no need):
> * RSA-encrypt and sign+encrypt keys - they are deprecated in
> RFC, GnuPG does not even give option to generate them, so IMO
> it's fine to ignore them.
> * Picking a key from list of keys - accepting a keyring in
> place of key.
> * Several encryption subkeys under one key.
> * Any form of signing - that also means no key integrity checks
> (eg - does the subkey belong to master key).
>
>
> Now, the code is significant in the following respect - the
> module 'contrib/pgcrypto' is complete. As I said, I don't
> think rest of the OpenPGP makes sense here, and there isn't
> any other generally-useful crypto functionality that would be
> good to have.
>
>
> Still, there are various things to do:
>
> 1. Polishing of the new PGP code.
> 2. Rework documentation and add FAQ.
> 3. Try to extract OpenSSL and zlib settings from main
> PostgreSQL config. Basically that means that ./configure
> should put them to separate variables, not into main CFLAGS.
> 4. Include strong RNG. Yarrow, Fortuna, ?.
> This is for both symmetricy and public-key encryption.
> 5. Include bignum code (only ops needed for Elgamal).
> This is for public-key encrypt/decrypt.
> 6. Propose crypt(), gen_salt() into mainline for 8.2.
> They are self-contained, except crypt-md5 depends on a MD5
> implentation, which already exists in mainline.
>
>
> Points 4 and 5 are suspicious - I'm not yet sure it can
> be done in manageable way. But without those, the PGP
> functions are unusable in default build. It may not be that
> bad - Yarrow/Fortuna seem to be small pieces only requiring
> external cipher and hash, which we have. And I could
> drop parts of libtommath into separate directory. But
> I don't think such things should be done in hurry.
>
> In the end, I think the code can go into 8.1 in current state -
> requiring OpenSSL. I'll look into dependencies in
> 8.2 timeframe.
>
> --
> marko
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq