[dm-crypt] inner workings of block mode encryption

[dm-crypt] inner workings of block mode encryption

[U.Mutlu]

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?

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.

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.

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?

-- 
TIA
Uenal

Re: [dm-crypt] inner workings of block mode encryption

[Ralf Ramsauer]

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.

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.

cheers
  Ralf

Re: [dm-crypt] inner workings of block mode encryption

[U.Mutlu]

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

Re: [dm-crypt] inner workings of block mode encryption

[Heinz Diehl]

On 08.02.2015, U.Mutlu wrote: 

> 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).

Neither AES, serpent nor twofish are prone to known-plaintext attacks.
Breaking some rounds is not the same as breaking the cipher.

> 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.

You're mixing symmetric/asymmetric crypto and block cipher modes. A stream
cipher is a symmetric key cipher. The random keystream is used to encrypt the
plaintext, using its seed as the "key". (Btw: dm-crypt works symmetrically, too).
An example for asymmetric encryption would be GPG, which uses a public/private
keypair.

What you describe reminds me on the (ages old - around 1980?) CBC mode, where the IV is
derived from the previous encrypted block. The first plaintext block is xor'ed
to an IV with the same size as the plaintext block itself. CBC is therefore prone to
choosen plaintext attacks. The last "C" in the name says it.
 
All of this is by no means specific for LUKS/dmcrypt. And there are surely a
lot of others with deeper knowledge who can explain this better to you..

Re: [dm-crypt] inner workings of block mode encryption

[Ralf Ramsauer]

Hi

On 02/08/2015 06:42 PM, Heinz Diehl wrote:
>> 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).
> Neither AES, serpent nor twofish are prone to known-plaintext attacks.
> Breaking some rounds is not the same as breaking the cipher.
>
I absolutely agree, Heinz.

Only the knowledge of a plain text block an the corresponding cipher
text block is NOT sufficient to "guess" or derive the key.
This is one of the major design criteria of symmetric block ciphers.

When I did my first steps in cryptography I also naively thought that
knowing a cipher text and a corresponsing plain text automatically
offers the possibility to derive the key but this is absolutely not the
truth.

And the use of the same key throughout your volume is NOT a vulnerability.

If you're of another opinion please show me references.

I recommend you to read the following links:
http://git.dyne.org/tomb/plain/doc/New_methods_in_HD_encryption.pdf
http://en.wikipedia.org/wiki/Watermarking_attack
http://en.wikipedia.org/wiki/Disk_encryption_theory
http://cacr.uwaterloo.ca/hac/ <- great book, online available for free

cheers
  Ralf

Re: [dm-crypt] inner workings of block mode encryption

[Arno Wagner]

On Sun, Feb 08, 2015 at 22:34:22 CET, Ralf Ramsauer wrote:
> Hi
> 
> On 02/08/2015 06:42 PM, Heinz Diehl wrote:
> >> 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).
> > Neither AES, serpent nor twofish are prone to known-plaintext attacks.
> > Breaking some rounds is not the same as breaking the cipher.
> >
> I absolutely agree, Heinz.
> 
> Only the knowledge of a plain text block an the corresponding cipher
> text block is NOT sufficient to "guess" or derive the key.
> This is one of the major design criteria of symmetric block ciphers.
> 
> When I did my first steps in cryptography I also naively thought that
> knowing a cipher text and a corresponsing plain text automatically
> offers the possibility to derive the key but this is absolutely not the
> truth.

And information-theoretically it does. It is just computational
effort that stands in between and computationel effort is tricky,
but also very real in this universe.

> And the use of the same key throughout your volume is NOT a vulnerability.

It is not. What is a vulnerablility is that the same key is used
for multiple writes to the same sector. It does not allow decryption,
but it does allow seeing whether a sector has changed if the attacker
can access the volume several times. 

This is also unavoidable when block sizes are mapped 1:1, metadata is 
of fixed size, and performance needs to be not too badly impacted. 
Hence it is accepted as a known limitation. 

Crypto is not perfect. Most crypto has known limitations and
vulnerabilities. The trick is to use the right method in the
right situation so that an attacker does not gain anything 
substantial. Hence crypto security is always with respect to
an attacker model (or equivalently, a set of attacker 
capabilities).

In addition, an attacker that can access a computer 2 or more times 
with the user unlocking the encrypted storage in between is generally 
assumed to have won in disk encryption, as this attacker can 
compromise the boot proccess. 
 
> If you're of another opinion please show me references.
> 
> I recommend you to read the following links:
> http://git.dyne.org/tomb/plain/doc/New_methods_in_HD_encryption.pdf
> http://en.wikipedia.org/wiki/Watermarking_attack
> http://en.wikipedia.org/wiki/Disk_encryption_theory
> http://cacr.uwaterloo.ca/hac/ <- great book, online available for free

I second that. In particular the thesis by Clemens is excellent.

It is not that we think you have no clue and should go away, it 
is that it is very hard talking to you when we have to clear up 
beginners mistakes all the time. Crypto is hard and complicated, 
some knowledge is required to even ask questions well.

Gr"usse,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] inner workings of block mode encryption

[Arno Wagner]

On Sun, Feb 08, 2015 at 17:31:49 CET, U.Mutlu wrote:
> Ralf Ramsauer wrote, On 02/08/2015 03:22 PM:
[...]
> 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).

With modern block-ciphers there is no "easily" here. In fact there 
is "infeasible" here as you basically always can get some ciphertext/
plaintext pairs also in communication encryption and it does not
even need to be a "chosen plaintext" attack. Ciphers vulnerable to
that are worthless.

Really, you need to read up on what modern ciphers do. You also
need to read up on the terminology. Getting the meaning of 
"symmetric" and "asymmetric" wrong is a pretty bad mistake.
Not that I accuse you of anything, it is just that communication
gets hard if one side does not understand the basics.
 
> 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.

That is infeasible for block-layer encryption and very expensive for
file-level encryption. Hence nobody does it on system layer. You may
be thinkling of things like CBC-mode communication encryption. Block-
device storage is not a communication device, it works differently.
For character-device storage where you do never seek you could do 
this, but you donot get a file-system on these, just a raw 
bit-stream.
 
> >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.

You think wrong. This problem has been studied for at least
two decades and nobody found a solution for it. In fact, it
can very likely be formally proven that this problem cannot
be solved and keep the security guarantees intact.

Gr"usse,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier