Thread: Documentation of pgcrypto AES key sizes
Hi, I noticed that the documentation for encrypt()/decrypt() says "aes — AES (Rijndael-128)", but in fact 192 and 256 bit keys are also supported, whether you build --with-openssl or --without-openssl. Should that say "AES (Rijndael-128, -192 or -256)" instead? -- Thomas Munro http://www.enterprisedb.com
On Fri, Jan 26, 2018 at 12:33:41PM +1300, Thomas Munro wrote: > I noticed that the documentation for encrypt()/decrypt() says "aes — > AES (Rijndael-128)", but in fact 192 and 256 bit keys are also > supported, whether you build --with-openssl or --without-openssl. > Should that say "AES (Rijndael-128, -192 or -256)" instead? Indeed. Instead of using the keysize as a prefix, I would personally find less confusing if written as "AES (Rijndael with key sizes of 128, 192 or 256 bytes)" instead of the phrasing you are proposing. Well, it is true that "Rijndael-128" and friends are wordings that can be found here and there.. -- Michael
Attachment
On Thu, Jan 25, 2018 at 8:19 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, Jan 26, 2018 at 12:33:41PM +1300, Thomas Munro wrote:
>> I noticed that the documentation for encrypt()/decrypt() says "aes —
>> AES (Rijndael-128)", but in fact 192 and 256 bit keys are also
>> supported, whether you build --with-openssl or --without-openssl.
>> Should that say "AES (Rijndael-128, -192 or -256)" instead?
>
> Indeed. Instead of using the keysize as a prefix, I would personally
> find less confusing if written as "AES (Rijndael with key sizes of 128,
> 192 or 256 bytes)" instead of the phrasing you are proposing. Well, it
> is true that "Rijndael-128" and friends are wordings that can be found
> here and there..
encrypt() seems happy with a key of any length at all, although I
guess internally it must round up to the next larger size.
rhaas=# select v, min(n), max(n) from (select n, encrypt('hello
world'::bytea, ('\x' || repeat('00', n))::bytea, 'aes') v from
generate_series(1,100000) n) x group by 1;
v | min | max
------------------------------------+-----+--------
\x7489adda96bb9c30fb4932e07731571a | 1 | 16
\x20a25e2af113663852f4e7b7870835ff | 17 | 24
\x56cbe187babf7b5df62924d78a3a5099 | 25 | 100000
(3 rows)
The breakpoints are at 16 bytes = 128 bits and 24 bytes = 192 bits, so
that is consistent with Thomas's theory about what's going on under
the hood.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sat, Jan 27, 2018 at 4:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 8:19 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Fri, Jan 26, 2018 at 12:33:41PM +1300, Thomas Munro wrote:
>>> I noticed that the documentation for encrypt()/decrypt() says "aes —
>>> AES (Rijndael-128)", but in fact 192 and 256 bit keys are also
>>> supported, whether you build --with-openssl or --without-openssl.
>>> Should that say "AES (Rijndael-128, -192 or -256)" instead?
>>
>> Indeed. Instead of using the keysize as a prefix, I would personally
>> find less confusing if written as "AES (Rijndael with key sizes of 128,
>> 192 or 256 bytes)" instead of the phrasing you are proposing.
Thanks for confirming.
>> Well, it
>> is true that "Rijndael-128" and friends are wordings that can be found
>> here and there..
Yeah, I think the convention of <algorithm> + <key-size-in-bits> is
widely understood, used elsewhere on the page ("SHA256", "aes256" used
with pgp_sym_encrypt, etc) and I'm not sure this is the right place to
explain it (you probably wouldn't be using raw crypto functions if you
don't know what these are). Perhaps we could be more verbose about
some things, including discussion of padding and truncation (see
below), but perhaps that could be a separate patch?
My goal here is just to clear up a factual error that confused someone
involved in an Oracle->PostgreSQL migration: they thought that
DBMS_CRYPTO could handle a particular key size that pgcrypto could
not, but pgcrypto can in fact handle all three sizes defined by AES.
> encrypt() seems happy with a key of any length at all, although I
> guess internally it must round up to the next larger size.
Right. It seems to zero-pad the key to reach the defined key sizes,
and truncate at 256 if you provided more than that. Slightly
surprising choices perhaps.
> rhaas=# select v, min(n), max(n) from (select n, encrypt('hello
> world'::bytea, ('\x' || repeat('00', n))::bytea, 'aes') v from
> generate_series(1,100000) n) x group by 1;
> v | min | max
> ------------------------------------+-----+--------
> \x7489adda96bb9c30fb4932e07731571a | 1 | 16
> \x20a25e2af113663852f4e7b7870835ff | 17 | 24
> \x56cbe187babf7b5df62924d78a3a5099 | 25 | 100000
> (3 rows)
>
> The breakpoints are at 16 bytes = 128 bits and 24 bytes = 192 bits, so
> that is consistent with Thomas's theory about what's going on under
> the hood.
Thanks for confirming. I also tested that it works whether you use
the OpenSSL code path (as I guess most people do) or the built-in
rijndael.c implementation.
Added to the next CF.
--
Thomas Munro
http://www.enterprisedb.com
Attachment
On Sun, Jan 28, 2018 at 6:02 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > Added to the next CF. Committed. I also modified the reference in the regression test along similar lines, and for good measure, I back-patched this change, as it constitutes a clear error in the documentation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company