On 10/18/21 17:56, Stephen Frost wrote:
>> ...
I've argued for storing the nonce, but I don't quite see why would we need
integrity guarantees?
AFAICS the threat model the patch aims to address is an attacker who can
observe the data (e.g. a low-privileged OS user), but can't modify the
files. Which seems like a reasonable model for shared environments.
There are multiple threat models which we should be considering and
that's why we may want to eventually add integrity.
So what are these threat models? If we should be considering them it'd
be nice to have a description, explaining what capabilities must the
attacker have ...
My (perhaps naive) understanding is that the authentication / integrity
provides (partial) protection against attackers that may modify instance
data - modify files, etc. But I'd guess an attacker with such capability
can do various other (simpler) things to extract data. Say, modify the
config to load an extension that dumps keys from memory, or whatever.
So what's a plausible / practical threat model that would be mitigated
by the authenticated encryption?
It'd be a bit silly to add complexity to allow AEAD, only to find out
there are ways around it.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
