On Mon, Jul 29, 2019 at 7:17 PM Sehrope Sarkuni <sehrope@jackdb.com> wrote:
>
> On Mon, Jul 29, 2019 at 4:39 AM Masahiko Sawada <sawada.mshk@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
