Re: [PATCH] pgcrypto: pgp_encrypt v3 - Mailing list pgsql-patches

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