Re: XTS cipher mode for cluster file encryption

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Sasasu <i(at)sasa(dot)su>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XTS cipher mode for cluster file encryption
Date: 2021-11-03 18:45:22
Message-ID: 20211103184522.GD20998@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Mon, Nov 1, 2021 at 02:24:36PM -0400, Stephen Frost wrote:
> > I can understand the general idea that we should be sure to engineer
> > this in a way that multiple methods can be used, as surely one day folks
> > will say that AES128 isn't acceptable any more. In terms of what we'll
> > do from the start, I would think providing the options of AES128 and
> > AES256 would be good to ensure that we have the bits covered to support
> > multiple methods and I don't think that would put us into a situation of
>
> My patch supports AES128, AES192, and AES256.

Right, so we're already showing that it's flexible to allow for multiple
encryption methods. If folks want more then it's on them to research
how they'd work exactly and explain why they'd be useful to add and how
users might make an informed choice (though, again, I don't think we
need to go *too* deep into that as we don't for, eg, pgcrypto, and I
don't believe we've ever heard people complain about that).

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-11-03 18:46:07 Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT.
Previous Message Simon Riggs 2021-11-03 17:50:54 Re: lastOverflowedXid does not handle transaction ID wraparound