Re: dm-crypt, new IV and standards

Re: dm-crypt, new IV and standards

[Adam J. Richter]

At 2004-02-19 22:20:37, Christophe Saout wrote:
>I've started to write a userspace program for reencryption. I don't know
>if this is very clever because I have to lock the part that is currently
>beeing reencrypted (deadlocks & co). Perhaps as another dm target like
>dm-mirror for pvmove? We'd have to keep a log or something because we
>don't *exactly* know what has been successfully written. This would mean
>a lot of seeks. It's complicated if it has to be safe against crashes
>and power outages.

	Device-mapper already has support for different regions of a
device being mapped differently (for example a single disk where
0-100GB is mapped to disk A, 100GB-200GB is mapped to disk B), and
I believe it has some support for changing this mapping while the
device is opened or mounted.  So, if you wanted to add support for
rekeying an encrypted block device while it is active, you could
probably do it in fewer lines of code with an approach based on
device-mapper than one based on a device.

	One scheme for reencryption with minimal extra seeks and
data transfers would be to configure a gap of, say, 128kB, at the
front (or back) of a block device.  During rekeying, this gap would
incrementally be moved forward (or backward).  The area before the
gap would be encrypted with key A, and the area after
the gap would be encrypted with key B.  Before you move the gap,
you arrange so that the old location of the gap has the same
contents as the new location of the gap, except that the old location
was encrypted with the old key, and the new location was encrypted with
the new key.  I can detail this more if my description is unclear,
but I suspect you get the picture.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America

Re: dm-crypt, new IV and standards

[Christophe Saout]

Am So, den 22.02.2004 schrieb Adam J. Richter um 20:20:

> >I've started to write a userspace program for reencryption. I don't know
> >if this is very clever because I have to lock the part that is currently
> >beeing reencrypted (deadlocks & co). Perhaps as another dm target like
> >dm-mirror for pvmove? We'd have to keep a log or something because we
> >don't *exactly* know what has been successfully written. This would mean
> >a lot of seeks. It's complicated if it has to be safe against crashes
> >and power outages.
> 
> 	Device-mapper already has support for different regions of a
> device being mapped differently (for example a single disk where
> 0-100GB is mapped to disk A, 100GB-200GB is mapped to disk B), and
> I believe it has some support for changing this mapping while the
> device is opened or mounted.  So, if you wanted to add support for
> rekeying an encrypted block device while it is active, you could
> probably do it in fewer lines of code with an approach based on
> device-mapper than one based on a device.

Yes, sure. As I said, I've already written something.

http://www.saout.de/misc/dm-convert-0.1.tar.bz2

I fixed it up so that it actually somehow. If it fails it leaves some
devices around that you'll have to remove by hand. It has support for
being interrupted and resumed later but I currently don't catch the
signal to put it into a reasonable state so don't interrupt it.

Syntax: dmconvert <source> <dest>

Where <source> and <dest> are the dm device names. <source> and <dest>
should be the same size and be backed by the same device (but can be
differently encrypted). <source> can be mounted and if dmconvert
finishes will use the mapping <dest> used, <dest> will be removed.

> 	One scheme for reencryption with minimal extra seeks and
> data transfers would be to configure a gap of, say, 128kB, at the
> front (or back) of a block device.  During rekeying, this gap would
> incrementally be moved forward (or backward).  The area before the
> gap would be encrypted with key A, and the area after
> the gap would be encrypted with key B.  Before you move the gap,
> you arrange so that the old location of the gap has the same
> contents as the new location of the gap, except that the old location
> was encrypted with the old key, and the new location was encrypted with
> the new key.  I can detail this more if my description is unclear,
> but I suspect you get the picture.

Yes. The block that is currently being converted is mapped to a third
temporary target that is suspended by dm so no I/O gets dispatched
there. Then the other two temporary targets are used to actually copy
that data (they contain the mappings of the original <source> and
<dest>). The <source> target (where the fs can be mounted on) maps to
all three temporary targets. After conversion of a block is finished,
the suspended target is resumed, the mappings updated and the next block
started.

If the machine crashes, well... good luck. :)

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

Agreed.  Good catch David.

JLC

On Wed, Mar 03, 2004 at 09:40:05PM +0000, David Wagner wrote:
> Jean-Luc Cooke  wrote:
> >Christophe and I's scheme of IV = firstIV + blockNum
> >for initial setup and IV = IV + 2^64 for IV updates will work fine
> 
> That's not ideal.  I'd suggest IV = HMAC_k(firstIV, blockNum) or somesuch.
> Sequential IV's aren't a good choice with CBC -- they can leak a little
> bit of information about the first block of plaintext, in some cases.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Thu, Mar 04, 2004 at 05:19:26PM -0800, dean gaudet wrote:
> On Thu, 4 Mar 2004, Jean-Luc Cooke wrote:
> 
> > recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
> > compute the N+1-th block without needing to know the output from the N-th
> > block, so there is the possibility for very high parallelizum).
> 
> for disk crypto there are other opportunities for parallelism using
> bitslicing to encrypt/decrypt multiple blocks in parallel (for example see
> <http://www.cs.utexas.edu/users/atri/papers/spaa.ps>).  there's a
> latency/throughput tradeoff though...

Humm.  Though AES uses GF's a lot, I think on 32bit processors bit slicing
AES just isn't worth it.

Though 512 byte fs blocks would only take 16 "transforms".  It's really hard
to implement ShiftRow() in bitwise SIMD...and x86 cpus simply don't have
enough registers (aliased or otherwise) to do this I think.  Fun read though!

JLC - bit-slicing MD5() will not improve things either, tried that for MD5CRK

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[dean gaudet]

On Thu, 4 Mar 2004, Jean-Luc Cooke wrote:

> recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
> compute the N+1-th block without needing to know the output from the N-th
> block, so there is the possibility for very high parallelizum).

for disk crypto there are other opportunities for parallelism using
bitslicing to encrypt/decrypt multiple blocks in parallel (for example see
<http://www.cs.utexas.edu/users/atri/papers/spaa.ps>).  there's a
latency/throughput tradeoff though...

-dean

Re: dm-crypt, new IV and standards

[David Wagner]

Jean-Luc Cooke  wrote:
>Like you said, CBC is not trivial to temper with - though it is do able.  CTR
>is trivial on the other hand.  Which is why NIST and every cryptographer will
>recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
>compute the N+1-th block without needing to know the output from the N-th
>block, so there is the possibility for very high parallelizum).

I'm worried about the potential for confusion, so let me clarify: Good
cryptographers will recommend using a MAC, whether you use CTR, CBC,
or CFB.  The need for a MAC is not specific to CTR; CBC is not exempt.

Re: dm-crypt, new IV and standards

[Pavel Machek]

Hi!

> > > Well, CTR mode is not recommended for encrypted file systems because it is very
> > > easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> > > If we add a MAC, then any mode of operation except ECB can be used for
> > > encrypted file systems.
> > 
> > what does "easy to corrupt" mean?  i haven't really seen disks generate
> > bit errors ever.  this MAC means you'll need to write integrity data for
> > every real write.  that really doesn't seem worth it...
> 
> The difference between "_1,000,000" and "_8,000,000" is 1 bit.  If an
> attacker knew enough about the layout of the filesystem (modify times on blocks,
> etc) they could flip a single bit and change your _1Mil purchase order
> approved by your boss to a _8Mil order.

Hmm... long time ago I created crc loop device to catch
faulty disks. If cryptoloop can do that for me... very good!
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Wed, Mar 03, 2004 at 05:48:46PM -0800, dean gaudet wrote:
> On Wed, 3 Mar 2004, Jean-Luc Cooke wrote:
> 
> > The difference between "$1,000,000" and "$8,000,000" is 1 bit.  If an
> > attacker knew enough about the layout of the filesystem (modify times on blocks,
> > etc) they could flip a single bit and change your $1Mil purchase order
> > approved by your boss to a $8Mil order.
> 
> ah ok i was completely ignoring the desire to prevent data tampering.
> 
> you have to admit it's still a bit more effort than flipping 1 bit like
> you suggest since you need to tweak the encrypted data enough so that the
> decrypted data has only 1 bit flipped.  (especially if you use CBC like
> you mention.)
> 
> something else which i've been wondering about -- would there be any extra
> protection provided by permuting block addresses so that the location of
> wellknown blocks such as the superblock and inode maps aren't so
> immediately obvious?  given the lack of known plaintext attacks on AES i'm
> thinking there's no point to permuting, but i'm not a cryptographer, i
> only know enough to be dangerous.  (you'd want to choose a permutation
> which makes some effort to group blocks into large enough chunks so that
> *some* seek locality can be maintained.)

I think there is not value in "security though obscurity" when you're
developing an open source application.  :)

Like you said, CBC is not trivial to temper with - though it is do able.  CTR
is trivial on the other hand.  Which is why NIST and every cryptographer will
recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
compute the N+1-th block without needing to know the output from the N-th
block, so there is the possibility for very high parallelizum).

JLC

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[dean gaudet]

On Wed, 3 Mar 2004, Jean-Luc Cooke wrote:

> The difference between "$1,000,000" and "$8,000,000" is 1 bit.  If an
> attacker knew enough about the layout of the filesystem (modify times on blocks,
> etc) they could flip a single bit and change your $1Mil purchase order
> approved by your boss to a $8Mil order.

ah ok i was completely ignoring the desire to prevent data tampering.

you have to admit it's still a bit more effort than flipping 1 bit like
you suggest since you need to tweak the encrypted data enough so that the
decrypted data has only 1 bit flipped.  (especially if you use CBC like
you mention.)

something else which i've been wondering about -- would there be any extra
protection provided by permuting block addresses so that the location of
wellknown blocks such as the superblock and inode maps aren't so
immediately obvious?  given the lack of known plaintext attacks on AES i'm
thinking there's no point to permuting, but i'm not a cryptographer, i
only know enough to be dangerous.  (you'd want to choose a permutation
which makes some effort to group blocks into large enough chunks so that
*some* seek locality can be maintained.)

-dean

Re: dm-crypt, new IV and standards

[David Wagner]

Jean-Luc Cooke  wrote:
>Christophe and I's scheme of IV = firstIV + blockNum
>for initial setup and IV = IV + 2^64 for IV updates will work fine

That's not ideal.  I'd suggest IV = HMAC_k(firstIV, blockNum) or somesuch.
Sequential IV's aren't a good choice with CBC -- they can leak a little
bit of information about the first block of plaintext, in some cases.

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Wed, Mar 03, 2004 at 12:35:07AM -0800, dean gaudet wrote:
> On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:
> 
> > Well, CTR mode is not recommended for encrypted file systems because it is very
> > easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> > If we add a MAC, then any mode of operation except ECB can be used for
> > encrypted file systems.
> 
> what does "easy to corrupt" mean?  i haven't really seen disks generate
> bit errors ever.  this MAC means you'll need to write integrity data for
> every real write.  that really doesn't seem worth it...

The difference between "$1,000,000" and "$8,000,000" is 1 bit.  If an
attacker knew enough about the layout of the filesystem (modify times on blocks,
etc) they could flip a single bit and change your $1Mil purchase order
approved by your boss to a $8Mil order.

Extraneous example to be sure.  But this is why you want MACs.  CBC mode is
more difficult to tamper with, but not immune.

> it seems like a block is either right, or it isn't -- the only thing the
> MAC is telling you is that the block isn't right... it doesn't tell you
> how to fix it.  that's a total waste of write bandwidth -- you might as
> well return the bogus decrypted block.

A block cipher can be viewed as a huge lookup table.  Converting a 128 bit
block of data (in the case of AES) into another using a single key as the
rule-set for this transformation.  This alone is not secure (think of the
attacks on ECB which does exactly this for all your data).  That's why we
have 6 modes of operation in common use in the industry.

ECB, CBC : block-mode
CFB, OFB : stream-moe
CTR      : block- and/mode stream-mode
OMAC     : 128bit keyed Message Authentication Code
CCM      : CTR + CBC-MAC defined by IEEE 802.11i 

> > [3] Why not use IV == block number or IV == firstIV + block number?
> > Certain modes of operation (like CTR) begin to leak information about the
> > plaintext if you ever use the same Key-IV pair for your data.
> > The IV will need to be updated every time you update the block.
> > The IV generation does need not be from a cryptographicly strong PRNG,
> > it need only be different from the previous IV.
> > So incrementing the IV by 1 mod 2^128 every time you write to the block will
> > suffice.
> 
> is CTR the only mode which is weak with simple IV / block number
> relationships?

CTR, ECB, and CFB are vulnerable.

> if you absolutely need this IV update for every write then you should
> consider a disk layout which mixes IV (or IV+MAC) blocks so that they are
> grouped near their data blocks, to reduce seek overhead.
> 
> i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by
> IV+MAC, followed by 15 data...

CBC mode doesn't absolutely need macs.  But the IV changes *are* required for
all modes of operation. Christophe and I's scheme of IV = firstIV + blockNum
for initial setup and IV = IV + 2^64 for IV updates will work fine as long as
there are less then 2^(128-64) block in the file system and less then 2^64
updates to any one block.  This scheme will keep CBC, OFB, CTR, and CCM modes
secure from eavesdropping but not Necessarily^[[1~^[[1~ from tampering.

JLC

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[dean gaudet]

On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:

> Well, CTR mode is not recommended for encrypted file systems because it is very
> easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> If we add a MAC, then any mode of operation except ECB can be used for
> encrypted file systems.

what does "easy to corrupt" mean?  i haven't really seen disks generate
bit errors ever.  this MAC means you'll need to write integrity data for
every real write.  that really doesn't seem worth it...

it seems like a block is either right, or it isn't -- the only thing the
MAC is telling you is that the block isn't right... it doesn't tell you
how to fix it.  that's a total waste of write bandwidth -- you might as
well return the bogus decrypted block.


> [3] Why not use IV == block number or IV == firstIV + block number?
> Certain modes of operation (like CTR) begin to leak information about the
> plaintext if you ever use the same Key-IV pair for your data.
> The IV will need to be updated every time you update the block.
> The IV generation does need not be from a cryptographicly strong PRNG,
> it need only be different from the previous IV.
> So incrementing the IV by 1 mod 2^128 every time you write to the block will
> suffice.

is CTR the only mode which is weak with simple IV / block number
relationships?

if you absolutely need this IV update for every write then you should
consider a disk layout which mixes IV (or IV+MAC) blocks so that they are
grouped near their data blocks, to reduce seek overhead.

i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by
IV+MAC, followed by 15 data...

-dean

Re: dm-crypt, new IV and standards

[Andreas Jellinghaus]

Sorry, I know next to nothing about dm-crypt or crypt loop so far.

But I wonder: will it be possible to store some generic data in that place?
Password+Hash mechanism+Salt seemt to be pretty tied to passwords.

I would like it very much, if some rsa encrypted data could be stored instead,
so I can use a smart card with an rsa key to decrypt it.

Regards, Andreas

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Sat, Feb 21, 2004 at 11:48:21AM -0500, Jean-Luc Cooke wrote:
> > Please focus your recommendations on security, not backward compatibility
> > with something that is new to the kernel tree, broken and maintainerless.
 
> I'll start writing OMAC now.

FYI OMAC spec:
  http://crypt.cis.ibaraki.ac.jp/omac/omac.html

As you can see, there is a fixed output no matter how large the input it, the
output is always 128 bits.

So how will this fit into the cipher.c interface?

        case CRYPTO_TFM_MODE_CTR:
                ops->cit_encrypt = omac_compute;
                ops->cit_decrypt = nocrypt;
                ops->cit_encrypt_iv = nocrypt_iv;
                ops->cit_decrypt_iv = nocrypt_iv;
                break;


But now the user will have to call cit_encrypt(tfm, dst[0], src[i], nbytes);
Notice how dest will always have to be dst[0].  Unless we use the hash interface.

Thoughts?

static int omac_encrypt(struct crypto_tfm *tfm,
                       struct scatterlist *dst,
                       struct scatterlist *src,
                       unsigned int nbytes)
{
        return crypt(tfm, dst, src, nbytes,
                     tfm->__crt_alg->cra_cipher.cia_encrypt,
                     omac_process, 1, tfm->crt_cipher.cit_iv);
}

JLC - has CTR mode implemented and will post once he has OMAC done as well.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Fri, Feb 20, 2004 at 04:26:04PM -0500, James Morris wrote:
> On Fri, 20 Feb 2004, Jean-Luc Cooke wrote:
> 
> > If others on the list care to do this, I'll give recommendation on how to 
> > implement the security (hmac, salt, iteration counts, etc).  But I think
> > this may break backward compatibility.  Can anyone speak to this?
> 
> Please focus your recommendations on security, not backward compatibility
> with something that is new to the kernel tree, broken and maintainerless.

Ah!  Ok.  :)  Here are my recommendations.

Well, CTR mode is not recommended for encrypted file systems because it is very
easy to corrupt single bits, bytes, blocks, etc without an integrity check.
If we add a MAC, then any mode of operation except ECB can be used for
encrypted file systems.

Also, current encrypted loop back FS's don't have integrity checks.  So we'll
need a place to store this information and update it every time a block is
updated.  For this we'll need to implement the OMAC authentication mode of
operation (I will do this now).  This will slow down the encryption process
of scatter-lists since we will now need to process the data twice (once for
confidentiality, and a second time to compute the message authentication code
- MAC).

At the head of the file system we'll need to store the following:
 - what block cipher is used
 - what mode of operation is used (ECB, OFB, CFB, CBC, CTR)
 - what password hashing algorithm is used, not MD5 (see [4])
 - what the password salt value is - 128 bit in length (see [1])
 - how many HMAC iterations are used to generate the key from the
   salt+password - 32 bit (see [2])

Some data will need to be stored with each block (or at least accessible
every time you encrypt/decrypt a block):
 - the IV - 128 bit in length (see [3])
 - the OMAC value - 128 bit in length

The hash algorithm:    Hash(data)
The HMAC algorithm:    HMAC(key, data)
The Encrypt algorithm: Enc(key, data)
The Decrypt algorithm: Dec(key, data)

Here is how I propose we compute the key (see [1][2]):
 K = HMAC(salt, password):
 for (i=0; i<iteration; i++)
   K = HMAC(salt, K);

Here is how I propose we compute the IV (see [3]):
 Reading a block:
  thisIV = readFromBlock(blockNum);
  /* ... decrypt the block with thisIV ... */

 Writing a block:
  thisIV = readFromBlock(blockNum);
  nextIV = INCMODP128(thisIV); /* nextIV = (thisIV + 1) mod 2^128 */
  /* ... encrypt the block with nextIV ... */

I'm sure there are implementation issues here, please let me know what they
are and we'll see what we can do.

I'll start writing OMAC now.

JLC

[1] Why have a salt?
You want to have salt of adequate size to make precomputing a dictionary of
Hash(...) outputs and thus quickly find the password.  This is common
practice in things like /etc/shadow so I shouldn't get much argument of this
implementation.
Adding a N-bit salt increases the space complexity of an attack by 2^N.

[2] Why iterate the password so many time?
If an attack requires 1 day to iterate though all 8 alphanumeric passwords,
adding a N-iteration hashing will push the attackers time complexity out by a
factor of N.  A iteration value of 2^16 (65536) should be adequate for our
purposes.

[3] Why not use IV == block number or IV == firstIV + block number?
Certain modes of operation (like CTR) begin to leak information about the
plaintext if you ever use the same Key-IV pair for your data.
The IV will need to be updated every time you update the block.
The IV generation does need not be from a cryptographicly strong PRNG,
it need only be different from the previous IV.
So incrementing the IV by 1 mod 2^128 every time you write to the block will
suffice.

[4] What not MD5?
MD5 has been deprecated by every cryptographer of good repute because it is not
being cryptographicly secure against collision attacks (read www.md5crk.com for
more information - shameless plug I know).  Though in this case we're using salted
HMACs, there is no exposure to collision attacks.  It's just good to push people
to use forward-looking algorithms since it's so easy to do so.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Carl-Daniel Hailfinger]

Jari,

since mainline cryptoloop/dm-crypt implementation is being changed right
now and you were complaining about it in the past, can you participate in
the discussions (there's also a parallel thread titled "[PATCH/proposal]
dm-crypt: add digest-based iv generation mode") so you don't have to
complain afterwards?

James Morris wrote:
> On Fri, 20 Feb 2004, Jean-Luc Cooke wrote:
> 
> 
>>If others on the list care to do this, I'll give recommendation on how to 
>>implement the security (hmac, salt, iteration counts, etc).  But I think
>>this may break backward compatibility.  Can anyone speak to this?
> 
> 
> Please focus your recommendations on security, not backward compatibility
> with something that is new to the kernel tree, broken and maintainerless.


Thanks,
Carl-Daniel

Re: dm-crypt, new IV and standards

[James Morris]

On Fri, 20 Feb 2004, Jean-Luc Cooke wrote:

> If others on the list care to do this, I'll give recommendation on how to 
> implement the security (hmac, salt, iteration counts, etc).  But I think
> this may break backward compatibility.  Can anyone speak to this?

Please focus your recommendations on security, not backward compatibility
with something that is new to the kernel tree, broken and maintainerless.

Thanks,


- James
-- 
James Morris
<jmorris@redhat.com>

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

If others on the list care to do this, I'll give recommendation on how to 
implement the security (hmac, salt, iteration counts, etc).  But I think
this may break backward compatibility.  Can anyone speak to this?

JLC


On Thu, Feb 19, 2004 at 11:20:37PM +0100, Christophe Saout wrote:
> Exactly. I like the format LVM2 uses. It basically puts the metadata
> into a text file with a magic header string there.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Christophe Saout]

Am Do, den 19.02.2004 schrieb Carl-Daniel Hailfinger um 23:06:

> Would it be sensible (AFAICS there is not technical limitation) to reserve
> 512/1024/2048/whatever bytes at the beginning of every backing device for
> dm-crypt so that the dm-crypt device could get some info about the used
> methods automatically?

All this can be done in userspace by the setup tool. It then tells the
kernel to start the device at a certain offset. It also has the
advantage that you can change your password without needing to reencrypt
your data (you keep your master key in the "superblock" encrypted with
the passphrase).

> So this meta-information superblock could contain the following:
> - A magic string like CRYPTSPACE (like SWAPSPACE2)
> - The key used to encrypt the device (the key would be encrypted with the
> password)
> - The IV algorithm used
> - The cipher used
> - The way the password was hashed
> - If some conversion was underway last time the dm-crypt device was accessed

Exactly. I like the format LVM2 uses. It basically puts the metadata
into a text file with a magic header string there.

> This way, the following benefits would appear:
> - New dm-crypt devices can be differentiated from old cryptoloop ones
> - Since the password is independent of the key, you can change the
> password without reencrypting the entire device.
> - Since the key is independent of the password, you can change the key,
> reencrypt the entire device and still keep your old password.
> - You can change the default IV to something more secure than the current
> default one without having to fear userland breakage.
> - There are multiple ways to hash a password and with the current scheme
> we have to try all of them if we do not know which version of the tools
> was used to create the file.
> - If the device is currently being reencrypted and is halfway through and
> the power fails, we would know that some part of the device is old
> encryption and some part is new encryption.

I've started to write a userspace program for reencryption. I don't know
if this is very clever because I have to lock the part that is currently
beeing reencrypted (deadlocks & co). Perhaps as another dm target like
dm-mirror for pvmove? We'd have to keep a log or something because we
don't *exactly* know what has been successfully written. This would mean
a lot of seeks. It's complicated if it has to be safe against crashes
and power outages.

> - New (more secure) crypto algorithms/ IV generation schemes/ passphrase
> hashing schemes could be added (or even made default) without violating
> the principle of least surprise.

Yes.

> I am not an expert in crypto, so if you tell me this would reduce security
> or cause other problems, I will accept that. I am aware that the more
> information an attacker has, the easier it is for him to break the encryption.

Other people are already doing this. And I'm not a crypt expert either.
I was just interested in device-mapper and just copied the mechanism
cryptoloop used... (but I'm not completely stupid either ;))

dm-crypt, new IV and standards

[Carl-Daniel Hailfinger]

Hi,

after having read what I believe to be all dm-crypt related mails on lkml,
I have a question which I could not find an answer for:
(and I noticed Andrew Morton worrying about backwards compatibility)

Would it be sensible (AFAICS there is not technical limitation) to reserve
512/1024/2048/whatever bytes at the beginning of every backing device for
dm-crypt so that the dm-crypt device could get some info about the used
methods automatically?

So this meta-information superblock could contain the following:
- A magic string like CRYPTSPACE (like SWAPSPACE2)
- The key used to encrypt the device (the key would be encrypted with the
password)
- The IV algorithm used
- The cipher used
- The way the password was hashed
- If some conversion was underway last time the dm-crypt device was accessed

This way, the following benefits would appear:
- New dm-crypt devices can be differentiated from old cryptoloop ones
- Since the password is independent of the key, you can change the
password without reencrypting the entire device.
- Since the key is independent of the password, you can change the key,
reencrypt the entire device and still keep your old password.
- You can change the default IV to something more secure than the current
default one without having to fear userland breakage.
- There are multiple ways to hash a password and with the current scheme
we have to try all of them if we do not know which version of the tools
was used to create the file.
- If the device is currently being reencrypted and is halfway through and
the power fails, we would know that some part of the device is old
encryption and some part is new encryption.
- New (more secure) crypto algorithms/ IV generation schemes/ passphrase
hashing schemes could be added (or even made default) without violating
the principle of least surprise.

I am not an expert in crypto, so if you tell me this would reduce security
or cause other problems, I will accept that. I am aware that the more
information an attacker has, the easier it is for him to break the encryption.


Regards,
Carl-Daniel