From: Milan Broz <gmazyland@gmail.com>
To: oSumAtrIX <johan.melkonyan1@web.de>, cryptsetup@lists.linux.dev
Subject: Re: Derive encryption key from PIN
Date: Tue, 14 Jul 2026 13:07:50 +0200 [thread overview]
Message-ID: <51d1a047-3f48-4447-bc44-59a16e650b94@gmail.com> (raw)
In-Reply-To: <CAK+fmzxEkGy+8X9BAwFKyU415Z4xm2uHfL+yaah-U1Rkw9YDYA@mail.gmail.com>
On 7/14/26 12:27 PM, oSumAtrIX wrote:
> I am reaching out because I noticed that the PIN used to unseal the
> decryption key from the TPM is not used to derive the decryption key.
> The PIN is merely used as a policy, when it can also function in a
> cryptographic context. The sealed key can further be encrypted with
> the PIN, so that even a full compromise of the TPM including the
> sealed key does not reveal the decryption key in cleartext. According
> to
> https://www.sstic.org/media/SSTIC2011/SSTIC-actes/bitlocker/SSTIC2011-Slides-bitlocker-bordes.pdf
> BitLocker implements a KDF from the TPM PIN, but it seems to be
> missing in LUKS.
Policies like FIPS strictly says that encryption key must be generated
from approved RNG. This is also LUKS logic (unless you specify
volume key explicitly).
What you probably mean is derived key to unlock keyslot (where volume key is stored).
And here it is up to token handling it, cryptsetup does not implement TPM unlocking,
it is systemd-cryptsetup/sysremd-cryptenroll configured token, so check policies there.
Anyway, Bitlocker TPM PIN is not used to derive encryption key either.
It can be used for TPMandPIN key protector (this is similar to LUKS keyslot).
Milan
prev parent reply other threads:[~2026-07-14 11:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 10:27 Derive encryption key from PIN oSumAtrIX
2026-07-14 10:57 ` Ondrej Kozina
2026-07-14 11:10 ` oSumAtrIX
2026-07-14 11:19 ` Ondrej Kozina
2026-07-14 11:07 ` Milan Broz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51d1a047-3f48-4447-bc44-59a16e650b94@gmail.com \
--to=gmazyland@gmail.com \
--cc=cryptsetup@lists.linux.dev \
--cc=johan.melkonyan1@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox