Re: [PATCHES] [PATCH] pgcrypto: pgp_encrypt v3

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,
Pennsylvania19073