On Mon, Jul 29, 2019 at 7:17 PM Sehrope Sarkuni <sehr...@jackdb.com> wrote: > > On Mon, Jul 29, 2019 at 4:39 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > After more thoughts, I'm confused why we need to have MDEK. We can use > > KEK derived from passphrase and TDEK and WDEK that are derived from > > KEK. That way, we don't need store any key in database file. What is > > the advantage of 3-tier key architecture? > > The separate MDEK serves a couple purposes: > > 1. Allows for rotating the passphrase without actually changing any of > the downstream derived keys. > 2. Verification that the passphrase itself is correct by checking if > it can unlock and authenticate (via a MAC) the MDEK. > 3. Ensures it's generated from a strong random source (ex: /dev/urandom). > > If the MDEK was directly derived via a deterministic function of the > passphrase, then that passphrase could never change as all your > derived keys would also change (and thus could not be decrypt their > existing data). The encrypted MDEK provides a level of indirection for > passphrase rotation.
Understood. Thank you for explanation! > > 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? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
