On Fri, Jan 31, 2020 at 1:21 AM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > On Thu, 30 Jan 2020 at 20:36, Sehrope Sarkuni <sehr...@jackdb.com> wrote: > > That > > would allow the internal usage to have a fixed output length of > > LEN(IV) + LEN(HMAC) + LEN(DATA) = 16 + 32 + 64 = 112 bytes. > > Probably you meant LEN(DATA) is 32? DATA will be an encryption key for > AES256 (master key) internally generated.
No it should be 64-bytes. That way we can have separate 32-byte encryption key (for AES256) and 32-byte MAC key (for HMAC-SHA256). While it's common to reuse the same 32-byte key for both AES256 and an HMAC-SHA256 and there aren't any known issues with doing so, when designing something from scratch it's more secure to use entirely separate keys. > > For the user facing piece, padding would enabled to support arbitrary > > input data lengths. That would make the output length grow by up to > > 16-bytes (rounding the data length up to the AES block size) plus one > > more byte if a version field is added. > > I think the length of padding also needs to be added to the output. > Anyway, in the first version the same methods of wrapping/unwrapping > key are used for both internal use and user facing function. And user > input key needs to be a multiple of 16 bytes value. A separate length field does not need to be added as the padding-enabled output will already include it at the end[1]. This would be handled automatically by the OpenSSL encryption / decryption operations (if it's enabled): [1]: https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS#5_and_PKCS#7 > BTW I think this topic is better to be discussed on a separate thread > as the scope no longer includes TDE. I'll start a new thread for > introducing internal KMS. Good idea. Regards, -- Sehrope Sarkuni Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
