All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Authenticated Encryption for dm-crypt
Date: Tue, 21 May 2013 04:17:14 +0200	[thread overview]
Message-ID: <20130521021714.GA563@tansi.org> (raw)
In-Reply-To: <519AB8C5.7090908@ramses-pyramidenbau.de>

On Tue, May 21, 2013 at 01:59:01AM +0200, Ralf Ramsauer wrote:
> Hi,
> On 05/21/2013 01:41 AM, Arno Wagner wrote:
> > I am not really sure what you mean. 
> >
> > Per-sector authenticatipn is infeasible as it requires 
> > additional space. This is not communication encryption
> > where attaching a few bytes is possible. This is disk
> > encryption where 512 encrypted bytes have to fit exactly
> > into 512 bytes of space. 
> Well additional space is no problem in my point of view. 

Sorry, but it is a massive problem. This has been tried
before with massively negative impact on performance
and data integrity. 

> Let's assume we
> would tag a 512 sector with a "Mac" with 20 bytes length.
> Then we would need ~20GiB for Tags for a disk with a size of 500GiB. We
> still would have 480GiB for bulk data. In my opinion
> that's a fair deal. 

The additional space is not the problem. The problem is keeping 
data and additonal data consistent and keeping head-movements 
minimal. There is quite a bit of discussion and literature
around about these problems as this gets proposed time and again. 
If I remember correctly, some people even tried with custom disks 
that had 540 byte sectors or something like that. All efforts failed,
this idea always dies as soon as practical filesystem aspects come 
into play. 

> The problem of the sector size could be solved by
> tagging larger amounts of data with larger tags. I know
> that's not really more secure but it solves the problem with the sector
> size (e.g. tag 4KiB of data with 512 Byte Tags or sth. like that).

This fails once you have 512B writes. 

Arno



> > Do you mean the header should authenticate itself to the 
> > user in decryption? That would only make sense if a 
> > malicious disk encryption system is assumed and would 
> > have to be done before the passphrase is given. The
> > attacker model would be something like disk-impersonation
> > gere or a cryptsetup or kernel that tries to steal the
> > passphrase.
> No, i meant the point you mentioned above.
> 
> Regards
> >
> > Arno
> >
> >
> > On Tue, May 21, 2013 at 12:31:09AM +0200, Ralf Ramsauer wrote:
> >> Hi,
> >>
> >> are there any weighty reasons why there is no support for authenticated
> >> encryption for
> >> dm-crypt or did simply no one want to implement it up to now? :-)
> >>
> >> Did anyone do any work on this topic up to now? I think authenticated
> >> encryption would
> >> be a nice feature.
> >>
> >> Regards
> >>
> >> -- 
> >> Ralf Ramsauer
> >>
> >> PGP: 0x8F10049B
> >>
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 
> -- 
> Ralf Ramsauer
> 
> PGP: 0x8F10049B
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

  reply	other threads:[~2013-05-21  2:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 22:31 [dm-crypt] Authenticated Encryption for dm-crypt Ralf Ramsauer
2013-05-20 23:41 ` Arno Wagner
2013-05-20 23:59   ` Ralf Ramsauer
2013-05-21  2:17     ` Arno Wagner [this message]
2013-05-21  7:24       ` octane indice
2013-05-21 13:58         ` Ralf Ramsauer
2013-05-21 17:22           ` Milan Broz

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=20130521021714.GA563@tansi.org \
    --to=arno@wagner.name \
    --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.