All of lore.kernel.org
 help / color / mirror / Atom feed
From: "U.Mutlu" <for-gmane@mutluit.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] inner workings of block mode encryption
Date: Sun, 08 Feb 2015 17:31:49 +0100	[thread overview]
Message-ID: <mb831m$4q8$1@ger.gmane.org> (raw)
In-Reply-To: <54D77140.3060804@ramses-pyramidenbau.de>

Ralf Ramsauer wrote, On 02/08/2015 03:22 PM:
> Hi,
>
> maybe you should start here:
> https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
>
> On 02/08/2015 03:06 PM, U.Mutlu wrote:
>> Hi,
>> I'm interessted in the inner workings of encrypting block devices
>> like the encrypted volumes created with the cryptsetup tool.
>>
>> Let's say a file of size 200K is stored on an encrypted ext2 filesystem.
>> How is the enrcyption key applied to it?
> To sum it up:
> cryptsetup is independent of the overlying filesystem and does not care
> about it.
> It just acts as a "mapper" and creates a new block device which
> represents plain text data.
> You can use this device for any purpose of your choice: create a
> filesystem on it, use it as a LVM Volume, ....
>>
>> I guess the password is used only for accessing/mounting the volume,
>> and the key is only a starting value (ie. a "seed") for the underlying
>> cipher.
> You can use a passphrase or a keyfile with cryptsetup LUKS.
> This key is applied to a key derivation function which derives an
> intermediate key which is used for decrypting a key slot which contains
> the actual master-key for decrypting your volume.
> This key slot or "lock box" concept opens the possibility that several
> key files or passphrases may unlock the volume.
> The material which is needed for decrypting the device is located in the
> LUKS header. See FAQ.
>>
>> Since in these cases usually a blockwise operating cipher is used,
>> that means that the file will be encrypted of course blockwise,
>> for example in blocks of 32 bytes.
> Yes, almost.
> dm-crypt uses a sector size of (correct me if i'm wrong) 512 Byte which
> means that every sector of 512 Byte gets en/decrypted independently.
> The encryption of each sector is parameterized by an initialization
> vector which may be influenced by the logical number of the sector.
>>
>> Now the question: are the blocks of that file all encrypted using the
>> same one key? Or does a kind of "streaming" or HMAC get used for the
>> subsequent blocks of the file?
> Well yes and no.
> Yes, the same key is used for all sectors of the volume and no, dm-crypt
> does not use HMAC to generate key streams.

Hmm. IMO this is the major weak point of such static/symmetric crypto solutions.
Knowing just one cleartext file, for example a well known static
system file from the /etc directory, and its encrpted data, could
easily lead to the master key (assuming the encrypted volume
contains such system files).

OTOH, a streaming crypto solution (I think also called 'asymmetric'),
ie. where each block gets encrypted with a new key derived from
the previous/initial key together with xoring with varying parts
of the user data in the block, would IMO make up a much more secure crypto 
solution.

> Just imagine: if you'd like to access the last sector of your volume
> you'd have to generate the whole key stream which would probably take a
> long time.

Yes, true, but I think this problem could be somehow solved.

>
> cheers
>    Ralf

-- 
cu
Uenal

  reply	other threads:[~2015-02-08 16:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-08 14:06 [dm-crypt] inner workings of block mode encryption U.Mutlu
2015-02-08 14:22 ` Ralf Ramsauer
2015-02-08 16:31   ` U.Mutlu [this message]
2015-02-08 17:42     ` Heinz Diehl
2015-02-08 21:34       ` Ralf Ramsauer
2015-02-09  2:14         ` Arno Wagner
2015-02-09  1:53     ` Arno Wagner

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='mb831m$4q8$1@ger.gmane.org' \
    --to=for-gmane@mutluit.com \
    --cc=dm-crypt@saout.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 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.