Re: [dm-crypt] GEOM_ELI support in dm-crypt/cryptsetup

[<f000m@z1p.biz>]

Hi Milan,

sorry for my late reply.

--- Ursprüngliche Nachricht ---
Von: Milan Broz <gmazyland@gmail.com>
Datum: 30.11.2013 18:33:02
An: f000m@z1p.biz
Betreff: Re: [dm-crypt] GEOM_ELI support in dm-crypt/cryptsetup

> Hi,
>
> On 11/30/2013 04:25 PM, f000m@z1p.biz wrote:
> > I am planing to make dm-crypt and cryptsetup able to
> > handle FreeBSD's GEOM_ELI crypted devices (without its
> > integrity stuff).
>
> I think that even integrity stuff would be interesting
> but that's a lot of kernel work.
> (But I am quite interested how FreeBSD approach looks like anyway.)
>
The first comment in the header file explains how it works.
http://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli_integrity.c?view=co

> > In the kernel modul there would be minor changes
> > concerning two more IV generators needed to add:
> > First, because of a slightly different handling of plain type
> > (it uses offsets instead of sectors).
> > Second, GEOM_ELI uses CBC with unpredictable IV instead of
> > ESSIV Mode.
>
> Not sure I understand offset/sectors problem.
> Can you elaborate more here? Is it just multiplication
> of sector number by sector size or something else?
> (Or just point me to the docs :)
>
Yes it is for plain mode. You can see it in g_eli_crypto_ivgen().
http://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?view=co

The unpredicable IV generation creates a SHA256 digest. It uses a IV seed
and the offset number (sector number by sector size).

Also it would need to add a routine to calculate (HMAC-SHA-512) the
encryption key on the fly because GEOM_ELI uses multiple encryption keys
since version 5. It uses a different key for every 2^20 sectors.
So I would put it in the IV generators, too.

> Anyway, adding new IV generators to dmcrypt should not be big problem
> (in principle).
>
> > Additionally cryptsetup must be patched to be able
> > to deal with the metadata structure of GEOM_ELI devices.
> >
> > Would there be any interests in committing me this code
> > to the upstream?
>
> Well, I am not sure how broadly this format is used and if
> there are potential users in Linux world, so if you can
> post more description here it would be nice.
>
It is a common tool in FreeBSD for cryptography. So it would be
nice one could access these FreeBSD devices with Linux, too (I think =).

> (And if anyone on list is interested, plesase say so... now :)
>
> But in general, yes, I think it is good idea.
>
> I would suggest you to do these steps:
>
> 1) provide links to documentation of format, limitation
> of your approach etc (also should be included in patch later)
>
> 2) first, implement needed changes in Linux kernel (dmcrypt IVs)
> (if it is only new IV, it should be straightforward)
> Please post patches to DM devel list (dm-devel@redhat.com)
>
> This should be done in advance - for testing, you can use
> dmsetup to configure dmcrypt device and test it works for your
> images.
>
> Cryptsetup support can come later (we need patch in stable kernel
> first to release build supporting it).
>
> 3) second, post patches for cryptsetup to this list.
>
> Please keep format specific code in separate directory,
> lib/geli/* or so.
> (I am planning some unified interface for formats in future (1.7),
> so see how is e.g. TCRYPT done - it should be very similar).
>
> Please post at least simple regression tests together with patches
> (see tests/ dir).
>
> License of new code must be compatible with released code,
> basically GPL2+/LGPL2.1+ for cryptsetup.
>
> (And be prepared it will take some time and perhaps reiterated
> patch posts - mainly for kernel part :)
>
> Thanks,
> Milan
>
Thanks for your suggestions.

Best regards.


______________________________________________________
powered by Secure-Mail.biz - anonymous and secure e-mail accounts.