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