All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Fomin <maxim@fomin.one>
To: development@efficientek.com
Cc: "grub-devel@gnu.org" <grub-devel@gnu.org>, "ps@pks.im" <ps@pks.im>
Subject: Re: [PATCH v6 1/1] plainmount: Support plain encryption mode
Date: Sat, 27 Aug 2022 20:50:30 +0000	[thread overview]
Message-ID: <MRFM7SKA5m3d_nyhW26gqvDrXV-3nfUDAhzj4AXzxraly3DvdqVLjh7708ewYw0bPxyWg4LqeMB4A4o8v-Xq7FDmHLfakcyVWOYY0kyZRMg=@fomin.one> (raw)
In-Reply-To: <20220827120519.262d4c06@crass-HP-ZBook-15-G2>


------- Original Message -------
On Saturday, August 27th, 2022 at 5:05 PM, Glenn Washburn <development@efficientek.com> wrote:
> 
> 
> On Sat, 27 Aug 2022 12:06:30 +0000
> Maxim Fomin maxim@fomin.one wrote:
> 
> > Also, I am confused about maximum key data and password size allowed by cryptomount.h. It
> > limits GRUB_CRYPTODISK_MAX_KEYLEN to 128, GRUB_CRYPTODISK_MAX_PASSPHRASE to 256 and
> > GRUB_CRYPTODISK_MAX_KEYFILE_SIZE to 8192. So, it looks like the passphrase (before hashing)
> > is limited to 256 bytes, when it is hashed - it is limited to hash size, which cannot be
> > larger than 128 bytes. Why then GRUB_CRYPTODISK_MAX_KEYFILE_SIZE is limited to 8192 bytes
> > (or bits?)? Also, if password is not hashed (-h plain) then 129 byte password becomes illegal,
> > because it is used directly as a key, which is limited to 128 bytes. Am I correct?
> 
> 
> The max keyfile size 4096 bytes, and I believe that is the cryptsetup
> default compiled in maximum. Yes, an unhashed 129 byte password will be
> longer than the max key length, this is okay because it should just be
> truncated to keysize. Cryptsetup looks like it fails when the password
> using the plain hash is of length less than key size. If it is more
> than keysize, then its fine, it just copies up to keysize bytes.
> 
> As far as keyfiles, plainmount is different than cryptomount, because
> keyfile data in plainmount is used as the encryption key, but in
> cryptomount its used as the password (ie the keyfile is hashed). I'm
> actually not sure if this conforms with cryptsetup, can you verify
> this? The documentation doesn't seem to specify.
> 

Yes, it specified in man cryptsetup in this section:

NOTES
   Passphrase processing for PLAIN mode
       Note that no iterated hashing or salting is done in plain mode. If hashing is done, it is a single direct hash. This means
       that low-entropy passphrases are easy to attack in plain mode.

       From a terminal: The passphrase is read until the first newline, i.e. '\n'. The input without the newline character is
       processed with the default hash or the hash specified with --hash. The hash result will be truncated to the key size of the
       used cipher, or the size specified with -s.

       From stdin: Reading will continue until a newline (or until the maximum input size is reached), with the trailing newline
       stripped. The maximum input size is defined by the same compiled-in default as for the maximum key file size and can be
       overwritten using --keyfile-size option.

       The data read will be hashed with the default hash or the hash specified with --hash. The hash result will be truncated to
       the key size of the used cipher, or the size specified with -s.

       Note that if --key-file=- is used for reading the key from stdin, trailing newlines are not stripped from the input.

       If "plain" is used as argument to --hash, the input data will not be hashed. Instead, it will be zero padded (if shorter than
       the key size) or truncated (if longer than the key size) and used directly as the binary key. This is useful for directly
       specifying a binary key. No warning will be given if the amount of data read from stdin is less than the key size.

       From a key file: It will be truncated to the key size of the used cipher or the size given by -s and directly used as a
       binary key.

       WARNING: The --hash argument is being ignored. The --hash option is usable only for stdin input in plain mode.

       If the key file is shorter than the key, cryptsetup will quit with an error. The maximum input size is defined by the same
       compiled-in default as for the maximum key file size and can be overwritten using --keyfile-size option.

Btw, it says also about keydata being truncated.


  reply	other threads:[~2022-08-27 20:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-31 17:32 [PATCH v6 1/1] plainmount: Support plain encryption mode Maxim Fomin
2022-08-23  6:14 ` Glenn Washburn
2022-08-27 12:06   ` Maxim Fomin
2022-08-27 17:05     ` Glenn Washburn
2022-08-27 20:50       ` Maxim Fomin [this message]
2022-09-14 16:15   ` Maxim Fomin
2022-09-15  0:54     ` Glenn Washburn
2022-09-15  5:28       ` Maxim Fomin
2022-09-16 20:55         ` Glenn Washburn

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='MRFM7SKA5m3d_nyhW26gqvDrXV-3nfUDAhzj4AXzxraly3DvdqVLjh7708ewYw0bPxyWg4LqeMB4A4o8v-Xq7FDmHLfakcyVWOYY0kyZRMg=@fomin.one' \
    --to=maxim@fomin.one \
    --cc=development@efficientek.com \
    --cc=grub-devel@gnu.org \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.