<orderedlist>
<listitem><para>Most prominently, the user may be queried interactively during volume activation
- (i.e. typically at boot), asking them to type in the necessary passphrase(s).</para></listitem>
+ (i.e. typically at boot), asking them to type in the necessary passphrases.</para></listitem>
<listitem><para>The (unencrypted) key may be read from a file on disk, possibly on removable media. The third field
of each line encodes the location, for details see above.</para></listitem>
then decrypted by the PKCS#11 token with an RSA key stored on it, and then used to unlock the encrypted
volume. Use the <option>pkcs11-uri=</option> option described below to use this mechanism.</para></listitem>
- <listitem><para>Similar, the key may be acquired via a FIDO2 compatible hardware security token (which
- must implement the "hmac-secret" extension). In this case a (during enrollment) randomly generated key
- is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in the LUKS2
- JSON token metadata header. The random key is hashed via a keyed hash function (HMAC) on the FIDO2
- token, using a secret key stored on the token that never leaves it. The resulting hash value is then
- used as key to unlock the encrypted volume. Use the <option>fido2-device=</option> option described
- below to use this mechanism.</para></listitem>
+ <listitem><para>Similarly, the key may be acquired via a FIDO2 compatible hardware security token
+ (which must implement the "hmac-secret" extension). In this case a key generated randomly during
+ enrollment is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in
+ the LUKS2 JSON token metadata header. The random key is hashed via a keyed hash function (HMAC) on the
+ FIDO2 token, using a secret key stored on the token that never leaves it. The resulting hash value is
+ then used as key to unlock the encrypted volume. Use the <option>fido2-device=</option> option
+ described below to use this mechanism.</para></listitem>
- <listitem><para>Similar, the key may be acquired via a TPM2 security chip. In this case a (during
+ <listitem><para>Similarly, the key may be acquired via a TPM2 security chip. In this case a (during
enrollment) randomly generated key — encrypted by an asymmetric key derived from the TPM2 chip's seed
key — is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in the
LUKS2 JSON token metadata header. Use the <option>tpm2-device=</option> option described below to use
for possible values and the default value of this option. A cipher with unpredictable IV values, such
as <literal>aes-cbc-essiv:sha256</literal>, is recommended. Embedded commas in the cipher
specification need to be escaped by preceding them with a backslash, see example below.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/>
</listitem>
</varlistentry>
<listitem><para>Allow discard requests to be passed through the encrypted block
device. This improves performance on SSD storage but has security implications.
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v207"/></listitem>
</varlistentry>
<varlistentry>
hashing. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for possible values and the default value of this
- option.</para></listitem>
+ option.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<term><option>header=</option></term>
- <listitem><para>Use a detached (separated) metadata device or
- file where the LUKS header is stored. This option is only
- relevant for LUKS devices. See
+ <listitem><para>Use a detached (separated) metadata device or file
+ where the header containing the master key(s) is stored. This
+ option is only relevant for LUKS and TrueCrypt/VeraCrypt devices. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- for possible values and the default value of this
- option.</para>
+ for possible values and the default value of this option.</para>
<para>Optionally, the path may be followed by <literal>:</literal> and an
<filename>/etc/fstab</filename> device specification (e.g. starting with <literal>UUID=</literal> or
similar); in which case, the path is relative to the device file system root. The device gets mounted
- automatically for LUKS device activation duration only.</para></listitem>
+ automatically for LUKS device activation duration only.</para>
+
+ <xi:include href="version-info.xml" xpointer="v219"/></listitem>
</varlistentry>
<varlistentry>
start of the key file. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for possible values and the default value of this
- option.</para></listitem>
+ option.</para>
+
+ <xi:include href="version-info.xml" xpointer="v187"/></listitem>
</varlistentry>
<varlistentry>
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for possible values and the default value of this option. This
option is ignored in plain encryption mode, as the key file
- size is then given by the key size.</para></listitem>
+ size is then given by the key size.</para>
+
+ <xi:include href="version-info.xml" xpointer="v188"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>If enabled, the specified key file is erased after the volume is activated or when
activation fails. This is in particular useful when the key file is only acquired transiently before
activation (e.g. via a file in <filename>/run/</filename>, generated by a service running before
- activation), and shall be removed after use. Defaults to off.</para></listitem>
+ activation), and shall be removed after use. Defaults to off.</para>
+
+ <xi:include href="version-info.xml" xpointer="v246"/></listitem>
</varlistentry>
<varlistentry>
<option>luks</option>. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for possible values. The default is to try all key slots in
- sequential order.</para></listitem>
+ sequential order.</para>
+
+ <xi:include href="version-info.xml" xpointer="v209"/></listitem>
</varlistentry>
<varlistentry>
<term><option>keyfile-timeout=</option></term>
<listitem><para> Specifies the timeout for the device on
- which the key file resides and falls back to a password if
- it could not be mounted. See
+ which the key file resides or the device used as the key file,
+ and falls back to a password if it could not be accessed. See
<citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for key files on external devices.
- </para></listitem>
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v243"/></listitem>
</varlistentry>
<varlistentry>
following options are ignored since they are provided by the
LUKS header on the device: <option>cipher=</option>,
<option>hash=</option>,
- <option>size=</option>.</para></listitem>
+ <option>size=</option>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<term><option>bitlk</option></term>
<listitem><para>Decrypt BitLocker drive. Encryption parameters
- are deduced by cryptsetup from BitLocker header.</para></listitem>
+ are deduced by cryptsetup from BitLocker header.</para>
+
+ <xi:include href="version-info.xml" xpointer="v246"/></listitem>
</varlistentry>
<varlistentry>
will be pulled in by <filename>local-fs.target</filename>, while the
service to configure the network is usually only started <emphasis>after</emphasis>
the local file system has been mounted.</para>
+
+ <xi:include href="version-info.xml" xpointer="v235"/>
</listitem>
</varlistentry>
This means that it will not be automatically unlocked on boot, unless something else pulls
it in. In particular, if the device is used for a mount point, it'll be unlocked
automatically during boot, unless the mount point itself is also disabled with
- <option>noauto</option>.</para></listitem>
+ <option>noauto</option>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
unsuccessful. Note that other units that depend on the unlocked device may still fail. In
particular, if the device is used for a mount point, the mount point itself also needs to
have the <option>nofail</option> option, or the boot will fail if the device is not unlocked
- successfully.</para></listitem>
+ successfully.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<term><option>offset=</option></term>
<listitem><para>Start offset in the backend device, in 512-byte sectors. This
- option is only relevant for plain devices.</para></listitem>
+ option is only relevant for plain devices.</para>
+
+ <xi:include href="version-info.xml" xpointer="v220"/></listitem>
</varlistentry>
<varlistentry>
<term><option>plain</option></term>
- <listitem><para>Force plain encryption mode.</para></listitem>
+ <listitem><para>Force plain encryption mode.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<term><option>read-only</option></term><term><option>readonly</option></term>
<listitem><para>Set up the encrypted block device in read-only
- mode.</para></listitem>
+ mode.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
an unbound workqueue so that encryption work is automatically balanced between available CPUs.</para>
<para>This requires kernel 4.0 or newer.</para>
+
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
benefits the CFQ scheduler to have writes submitted using the same context.</para>
<para>This requires kernel 4.0 or newer.</para>
+
+ <xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
</varlistentry>
default is to queue these requests and process them asynchronously.</para>
<para>This requires kernel 5.9 or newer.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/>
</listitem>
</varlistentry>
<varlistentry>
default is to queue these requests and process them asynchronously.</para>
<para>This requires kernel 5.9 or newer.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/>
</listitem>
</varlistentry>
with its number for IV generation being <replaceable>n</replaceable>.</para>
<para>This option is only relevant for plain devices.</para>
+
+ <xi:include href="version-info.xml" xpointer="v220"/>
</listitem>
</varlistentry>
<listitem><para>Specifies the key size in bits. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for possible values and the default value of this
- option.</para></listitem>
+ option.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Specifies the sector size in bytes. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
for possible values and the default value of this
- option.</para></listitem>
+ option.</para>
+
+ <xi:include href="version-info.xml" xpointer="v240"/></listitem>
</varlistentry>
<varlistentry>
<para>WARNING: Using the <option>swap</option> option will
destroy the contents of the named partition during every boot,
so make sure the underlying block device is specified
- correctly.</para></listitem>
+ correctly.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
to all key files. When using an empty passphrase in
combination with one or more key files, use
<literal>/dev/null</literal> as the password file in the third
- field.</para></listitem>
+ field.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/></listitem>
</varlistentry>
<varlistentry>
no protection for the hidden volume if the outer volume is
mounted instead. See
<citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- for more information on this limitation.</para></listitem>
+ for more information on this limitation.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/></listitem>
</varlistentry>
<varlistentry>
<para>See the entry for <option>tcrypt</option> on the
behavior of the passphrase and key files when using TrueCrypt
- encryption mode.</para></listitem>
+ encryption mode.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/></listitem>
</varlistentry>
<varlistentry>
<term><option>tcrypt-system</option></term>
<listitem><para>Use TrueCrypt in system encryption mode. This
- option implies <option>tcrypt</option>.</para></listitem>
+ option implies <option>tcrypt</option>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v206"/></listitem>
</varlistentry>
<varlistentry>
derivation algorithms that cannot be detected without this flag.
Enabling this option could substantially slow down unlocking, because
VeraCrypt's key derivation takes much longer than TrueCrypt's. This
- option implies <option>tcrypt</option>.</para></listitem>
+ option implies <option>tcrypt</option>.</para>
+
+ <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>veracrypt-pim=</option></term>
+
+ <listitem><para>Specifies a custom Personal Iteration Multiplier (PIM)
+ value, which can range from 0..2147468 for standard veracrypt volumes
+ and 0..65535 for veracrypt system volumes. A value of 0 will imply the
+ VeraCrypt default.
+
+ This option is only effective when <option>tcrypt-veracrypt</option> is
+ set.</para>
+
+ <para>Note that VeraCrypt enforces a minimal allowed PIM value depending on the
+ password strength and the hash algorithm used for key derivation, however
+ <option>veracrypt-pim=</option> is not checked against these bounds.
+ <ulink url="https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html">See
+ documentation</ulink> for more information.</para>
+
+ <xi:include href="version-info.xml" xpointer="v254"/>
+ </listitem>
</varlistentry>
<varlistentry>
<listitem><para>Specifies the timeout for querying for a
password. If no unit is specified, seconds is used. Supported
units are s, ms, us, min, h, d. A timeout of 0 waits
- indefinitely (which is the default).</para></listitem>
+ indefinitely (which is the default).</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
option implies <option>plain</option>.</para>
<para>WARNING: Using the <option>tmp</option> option will destroy the contents of the named partition
- during every boot, so make sure the underlying block device is specified correctly.</para></listitem>
+ during every boot, so make sure the underlying block device is specified correctly.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Specifies the maximum number of times the user
is queried for a password. The default is 3. If set to 0, the
- user is queried for a password indefinitely.</para></listitem>
+ user is queried for a password indefinitely.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
<term><option>headless=</option></term>
<listitem><para>Takes a boolean argument, defaults to false. If true, never query interactively
- for the password/PIN. Useful for headless systems.</para></listitem>
+ for the password/PIN. Useful for headless systems.</para>
+
+ <xi:include href="version-info.xml" xpointer="v249"/></listitem>
</varlistentry>
<varlistentry>
<term><option>verify</option></term>
<listitem><para>If the encryption password is read from console, it has to be entered twice to
- prevent typos.</para></listitem>
+ prevent typos.</para>
+
+ <xi:include href="version-info.xml" xpointer="v186"/></listitem>
</varlistentry>
<varlistentry>
(<literal>*</literal>) is echoed for each character typed. Regardless of
which mode is chosen, if the user hits the tabulator key (<literal>↹</literal>)
at any time, or the backspace key (<literal>⌫</literal>) before any other
- data has been entered, then echo is turned off.</para></listitem>
+ data has been entered, then echo is turned off.</para>
+
+ <xi:include href="version-info.xml" xpointer="v249"/></listitem>
</varlistentry>
<varlistentry>
implement the newer and simpler FIDO2 standard. Consider using <option>fido2-device=</option>
(described below) to enroll it via FIDO2 instead. Note that a security token enrolled via PKCS#11
cannot be used to unlock the volume via FIDO2, unless also enrolled via FIDO2, and vice
- versa.</para></listitem>
+ versa.</para>
+
+ <xi:include href="version-info.xml" xpointer="v245"/></listitem>
</varlistentry>
<varlistentry>
<para>Note that many security tokens that implement FIDO2 also implement PKCS#11, suitable for
unlocking volumes via the <option>pkcs11-uri=</option> option described above. Typically the newer,
- simpler FIDO2 standard is preferable.</para></listitem>
+ simpler FIDO2 standard is preferable.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
must be of LUKS2 type, and the CID is read from the LUKS2 JSON token header. Use
<citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for enrolling a FIDO2 token in the LUKS2 header compatible with this automatic
- mode.</para></listitem>
+ mode.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Takes a string, configuring the FIDO2 Relying Party (rp) for the FIDO2 unlock
operation. If not specified <literal>io.systemd.cryptsetup</literal> is used, except if the LUKS2
JSON token header contains a different value. It should normally not be necessary to override
- this.</para></listitem>
+ this.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
used to unlock the volume. When the randomized key is encrypted the current values of the selected
PCRs (see below) are included in the operation, so that different PCR state results in different
encrypted keys and the decrypted key can only be recovered if the same PCR state is
- reproduced.</para></listitem>
+ reproduced.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<varlistentry>
<command>systemd-cryptenroll</command> writes it there. If not used (and no metadata in the LUKS2
JSON token header defines it), defaults to a list of a single entry: PCR 7. Assign an empty string to
encode a policy that binds the key to no PCRs, making the key accessible to local programs regardless
- of the current PCR state.</para></listitem>
+ of the current PCR state.</para>
+
+ <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>tpm2-pin=</option></term>
+
+ <listitem><para>Takes a boolean argument, defaults to <literal>false</literal>. Controls whether
+ TPM2 volume unlocking is bound to a PIN in addition to PCRs. Similarly, this option is only useful
+ when TPM2 enrollment metadata is not available.</para>
+
+ <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>tpm2-signature=</option></term>
+
+ <listitem><para>Takes an absolute path to a TPM2 PCR JSON signature file, as produced by the
+ <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ tool. This permits locking LUKS2 volumes to any PCR values for which a valid signature matching a
+ public key specified at key enrollment time can be provided. See
+ <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ for details on enrolling TPM2 PCR public keys. If this option is not specified but it is attempted to
+ unlock a LUKS2 volume with a signed TPM2 PCR enrollment a suitable signature file
+ <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
+ <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this
+ order).</para>
+
+ <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>tpm2-measure-pcr=</option></term>
+
+ <listitem><para>Controls whether to measure the volume key of the encrypted volume to a TPM2 PCR. If
+ set to "no" (which is the default) no PCR extension is done. If set to "yes" the volume key is
+ measured into PCR 15. If set to a decimal integer in the range 0…23 the volume key is measured into
+ the specified PCR. The volume key is measured along with the activated volume name and its UUID. This
+ functionality is particularly useful for the encrypted volume backing the root file system, as it
+ then allows later TPM objects to be securely bound to the root file system and hence the specific
+ installation.</para>
+
+ <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>tpm2-measure-bank=</option></term>
+
+ <listitem><para>Selects one or more TPM2 PCR banks to measure the volume key into, as configured with
+ <option>tpm2-measure-pcr=</option> above. Multiple banks may be specified, separated by a colon
+ character. If not specified automatically determines available and used banks. Expects a message
+ digest name (e.g. <literal>sha1</literal>, <literal>sha256</literal>, …) as argument, to identify the
+ bank.</para>
+
+ <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>token-timeout=</option></term>
+
+ <listitem><para>Specifies how long to wait at most for configured security devices (i.e. FIDO2,
+ PKCS#11, TPM2) to show up. Takes a time value in seconds (but other time units may be specified too,
+ see <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+ for supported formats). Defaults to 30s. Once the specified timeout elapsed authentication via
+ password is attempted. Note that this timeout applies to waiting for the security device to show up —
+ it does not apply to the PIN prompt for the device (should one be needed) or similar. Pass 0 to turn
+ off the time-out and wait forever.</para>
+
+ <xi:include href="version-info.xml" xpointer="v250"/></listitem>
</varlistentry>
<varlistentry>
<listitem><para>Takes a boolean argument. If enabled, right before asking the user for a password it
is first attempted to unlock the volume with an empty password. This is useful for systems that are
initialized with an encrypted volume with only an empty password set, which shall be replaced with a
- suitable password during first boot, but after activation.</para></listitem>
+ suitable password during first boot, but after activation.</para>
+
+ <xi:include href="version-info.xml" xpointer="v246"/></listitem>
</varlistentry>
<varlistentry>
<term><option>x-systemd.device-timeout=</option></term>
- <listitem><para>Specifies how long systemd should wait for a device to show up
- before giving up on the entry. The argument is a time in seconds or explicitly
- specified units of
- <literal>s</literal>,
- <literal>min</literal>,
- <literal>h</literal>,
- <literal>ms</literal>.
- </para></listitem>
+ <listitem><para>Specifies how long systemd should wait for a block device to show up before
+ giving up on the entry. The argument is a time in seconds or explicitly specified units of
+ <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, <literal>ms</literal>.
+ </para>
+
+ <xi:include href="version-info.xml" xpointer="v216"/></listitem>
</varlistentry>
<varlistentry>
<term><option>x-initrd.attach</option></term>
- <listitem><para>Setup this encrypted block device in the initramfs, similarly to
+ <listitem><para>Setup this encrypted block device in the initrd, similarly to
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units marked with <option>x-initrd.mount</option>.</para>
use. With this option the device will still be detached but later after the root file
system is unmounted.</para>
- <para>All other encrypted block devices that contain file systems mounted in the initramfs
- should use this option.</para>
+ <para>All other encrypted block devices that contain file systems mounted in the initrd should use
+ this option.</para>
+
+ <xi:include href="version-info.xml" xpointer="v245"/>
</listitem>
</varlistentry>
project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details. The source socket name is chosen according the following format:</para>
- <programlisting><constant>NUL</constant> <replaceable>RANDOM</replaceable> <literal>/cryptsetup/</literal> <replaceable>VOLUME</replaceable></programlisting>
+ <programlisting><constant>NUL</constant> <replaceable>RANDOM</replaceable> /cryptsetup/ <replaceable>VOLUME</replaceable></programlisting>
<para>In other words: a <constant>NUL</constant> byte (as required for abstract namespace sockets),
followed by a random string (consisting of alphanumeric characters only), followed by the literal
string <literal>/cryptsetup/</literal>, followed by the name of the volume to acquire they key
- for. Example (for a volume <literal>myvol</literal>):</para>
+ for. For example, for the volume <literal>myvol</literal>:</para>
- <example><programlisting>\0d7067f78d9827418/cryptsetup/myvol</programlisting></example>
+ <programlisting>\0d7067f78d9827418/cryptsetup/myvol</programlisting>
<para>Services listening on the <constant>AF_UNIX</constant> stream socket may query the source socket
name with <citerefentry
project='man-pages'><refentrytitle>getpeername</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
- and use it to determine which key to send, allowing a single listening socket to serve keys for a
- multitude of volumes. If the PKCS#11 logic is used (see above) the socket source name is picked in
- identical fashion, except that the literal string <literal>/cryptsetup-pkcs11/</literal> is used (similar
- for FIDO2: <literal>/cryptsetup-fido2/</literal> and TPM2: <literal>/cryptsetup-tpm2/</literal>). This is
- done so that services providing key material know that not a secret key is requested but an encrypted key
- that will be decrypted via the PKCS#11/FIDO2/TPM2 logic to acquire the final secret key.</para>
+ and use this to determine which key to send, allowing a single listening socket to serve keys for
+ multiple volumes. If the PKCS#11 logic is used (see above), the socket source name is picked in similar
+ fashion, except that the literal string <literal>/cryptsetup-pkcs11/</literal> is used. And similarly for
+ FIDO2 (<literal>/cryptsetup-fido2/</literal>) and TPM2 (<literal>/cryptsetup-tpm2/</literal>). A different
+ path component is used so that services providing key material know that the secret key was not requested
+ directly, but instead an encrypted key that will be decrypted via the PKCS#11/FIDO2/TPM2 logic to acquire
+ the final secret key.</para>
</refsect1>
<refsect1>
projects / thirdparty / systemd.git / blobdiff