On Mon, Jul 29, 2019 at 8:18 PM Sehrope Sarkuni <sehr...@jackdb.com> wrote: > > On Mon, Jul 29, 2019 at 6:42 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > An argument could be made to push that problem upstream, i.e. let the > > > supplier of the passphrase deal with the indirection. You would still > > > need to verify the supplied passphrase/key is correct via something > > > like authenticating against a stored MAC. > > > > So do we need the key for MAC of passphrase/key in order to verify? > > Yes. Any 128 or 256-bit value is a valid AES key and any 16-byte input > can be "decrypted" with it in both CTR and CBC mode, you'll just end > up with garbage data if the key does not match. Verification of the > key prior to usage (i.e. starting DB and encrypting/decrypting data) > is a must as otherwise you'll end up with all kinds of corruption or > data loss. >
Do you mean that we encrypt and store a 16 byte input with the correct key to the disk, and then decrypt it with the user supplied key and compare the result to the input data? > From a single user supplied passphrase you would derive the MDEK and > compute a MAC (either using the same key or via a separate derived > MDEK-MAC key). If the computed MAC matches against the previously > stored value then you know the MDEK is correct as well. You meant KEK, not MDEK? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
