pgcrypto: PGP keyring FDW ?...

From: Bear Giles <bgiles(at)coyotesong(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: pgcrypto: PGP keyring FDW ?...
Date: 2024-11-08 02:42:59
Message-ID: CALBNtw7Lr4TXRW7OH9iFTcJaTRqdEbHiFjxLVoEt9s2QeGtiqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wanted to bounce a few related ideas off people.

Foreign Data Wrappers

One of the biggest vulnerabilities of the current system is the need for
the client to know the PGP key. There's a better alternative for many (not
all) use cases - loading the PGP key from a file located on the server or
securely downloaded from a trusted source on an as-needed basis.

In other words - a Foreign Data Wrapper for PGP keyrings. The initial
milestone could be a readonly table containing:

- keyid
- alg
- not_before
- not_after
- public key
- secret key (if available)

I've included type --list-keys below. I know the FDW should include the
[SCE] flags and '[unknown|lultimate|...] values, and possibly the uid
values. (It would need to be text[]). Secret keys add a 'ssb' element.

UDT and UDF

This still exposes a lot of information so it makes sense to consider a UDT
for PGP_KEY and possibly more. This UDT can be opaque - the secret key can
be write-only. Otherwise the UDT can be a drop-in replacement for the
existing text and bytea UDFs.

A similar idea, one that I'm still exploring, is PGP_CIPHERTEXT. It's a
drop-in replacement for bytea but makes it easy to add type-safe functions
to extract metadata from the ciphertext.

The keyring FDW would return a PGP_KEY for the secret key. This prevents
the exposure of a secret key loaded from a keyring.

Sample output of --list-keys

pub rsa4096 2011-02-08 [SCE]
BFC61E9C8BE9942EAE818A95E5D9A0503AD31D0B
uid [ unknown] Fedora-SPARC (15) <fedora(at)fedoraproject(dot)org>
sub elg4096 2011-02-08 [E]

pub rsa4096 2015-07-25 [SCE]
5048BDBBA5E776E547B09CCC73BDE98381B46521
uid [ unknown] Fedora (24) <fedora-24-primary(at)fedoraproject(dot)org>

pub rsa4096 2015-07-27 [SCE]
8C6E5A80A399BABE791985BAB8635EEB030D5AED
uid [ unknown] Fedora Secondary (24) <
fedora-24-secondary(at)fedoraproject(dot)org>
sub elg2048 2015-07-27 [E]

pub rsa4096 2016-03-31 [SCE]
C437DCCD558A66A37D6F43724089D8F2FDB19C98
uid [ unknown] Fedora 25 Primary (25) <
fedora-25-primary(at)fedoraproject(dot)org>

pub rsa4096 2016-03-31 [SCE]
838BD48E1B70069F4111BDE91A185CDDE372E838
uid [ unknown] Fedora 25 Secondary (25) <
fedora-25-secondary(at)fedoraproject(dot)org>
sub elg2048 2016-03-31 [E]

pub rsa4096 2016-09-09 [SCE]
E641850B77DF435378D1D7E2812A6B4B64DAB85D
uid [ unknown] Fedora 26 Primary (26) <
fedora-26-primary(at)fedoraproject(dot)org>

pub rsa4096 2016-08-08 [SCE]
19AA0442249191098B3D80354560FD4D3B921D09
uid [ unknown] Fedora 26 Secondary (26) <
fedora-26-secondary(at)fedoraproject(dot)org>
sub elg2048 2016-08-08 [E]

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2024-11-08 02:45:44 Re: Inconsistent RestrictInfo serial numbers
Previous Message Bear Giles 2024-11-08 02:15:00 pgcrypto: better memory management?...