From: Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Efficacy of xts over 1TB
Date: Mon, 26 Jul 2010 22:47:43 +0200 [thread overview]
Message-ID: <1280177263.3266.120.camel@fermat.scientia.net> (raw)
In-Reply-To: <20100726085319.GC12550@tansi.org>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On Mon, 2010-07-26 at 10:53 +0200, Arno Wagner wrote:
> > Well but as far as I understand, this means that the same IV could be
> > used in multiple sectors (after the 32bit), right?
> Err, no? That would be "after 64 bit".
Uhm why? If we have 64, bits but the upper 32 are masked 0 as far as I
understood... ?
> If you go over 64 bit sector numbers, definitely. However it is
> hard to quantify how large this impact would be.
But 64bit 512byte sectors would allow us a ~9,4 ZB device, right? So
that is unlikely to happen the next... say 3 years or so ;)
> > I see... what about this idea:
> > In newer releases of cryptsetup, give a warning whenever people use
> > "plain" suggesting them to use "plain64"?!
> I like this approach.
Thanks :) perhaps better than a warning would even be some interactive
question.
> I think this is out of scope. Somebody rezising an encrypted device
> without looking into the limits of the encryption used, is asking
> for trouble. Also there will be a FAQ entry on resizing ;-)
Well... if my calculation above is correct, we'd at least never leave
the scope with plain 64.
Nevertheless... it would be at least possible to change luksResize to
print a warning,.. but of course this won't happen in all cases (plain
dm-crypt, close/reopen), which is why I suggested plain64 to be
generally used,.. especially if it has not drawbacks.
Milan what do you think?
Cheers,
Chris.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]
next prev parent reply other threads:[~2010-07-26 20:47 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 14:57 [dm-crypt] Efficacy of xts over 1TB David Santamaría Rogado
2010-07-25 10:34 ` Arno Wagner
2010-07-25 11:18 ` Christoph Anton Mitterer
2010-07-25 12:29 ` Heinz Diehl
2010-07-25 12:25 ` Milan Broz
2010-07-25 13:14 ` Christoph Anton Mitterer
2010-07-25 13:52 ` Milan Broz
2010-07-25 22:37 ` Christoph Anton Mitterer
2010-07-26 0:14 ` Milan Broz
2010-07-26 20:38 ` Christoph Anton Mitterer
2010-07-27 8:46 ` [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt Milan Broz
2010-07-27 10:47 ` Arno Wagner
2010-07-27 14:17 ` Christoph Anton Mitterer
2010-07-27 16:08 ` Arno Wagner
2010-07-27 14:15 ` Christoph Anton Mitterer
2010-07-27 15:45 ` Mario 'BitKoenig' Holbe
2010-07-27 15:55 ` Milan Broz
2010-07-27 18:59 ` Christoph Anton Mitterer
2010-07-27 19:37 ` Arno Wagner
2010-07-27 18:58 ` Christoph Anton Mitterer
2010-07-27 19:35 ` Mario 'BitKoenig' Holbe
2010-07-28 8:42 ` Milan Broz
2010-08-20 21:11 ` [dm-crypt] XTS cipher mode limitations Christoph Anton Mitterer
2010-08-21 0:22 ` Arno Wagner
2010-08-22 12:50 ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer
2010-08-23 0:46 ` Arno Wagner
2010-08-25 9:36 ` Christoph Anton Mitterer
2010-08-22 12:56 ` [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) Christoph Anton Mitterer
2010-08-22 16:01 ` Arno Wagner
2010-08-22 21:57 ` Christoph Anton Mitterer
2010-08-23 7:14 ` [dm-crypt] tool to account the written number of bytes to a block device Milan Broz
2010-08-25 9:27 ` Christoph Anton Mitterer
2010-08-24 16:19 ` [dm-crypt] XTS cipher mode limitations Ramius
2010-07-26 8:53 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner
2010-07-26 20:47 ` Christoph Anton Mitterer [this message]
2010-07-26 21:01 ` Arno Wagner
2010-07-26 21:28 ` Christoph Anton Mitterer
2010-07-26 21:35 ` Arno Wagner
2010-07-25 22:52 ` Christoph Anton Mitterer
2010-07-26 9:42 ` Mario 'BitKoenig' Holbe
2010-07-26 18:09 ` Arno Wagner
2010-07-27 18:16 ` [dm-crypt] Including the FAQ in the tarball? Christoph Anton Mitterer
2010-07-27 18:23 ` Arno Wagner
2010-07-29 8:17 ` Heinz Diehl
2010-07-25 15:32 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner
2010-07-25 22:48 ` Christoph Anton Mitterer
2010-07-25 23:42 ` Milan Broz
2010-07-26 18:35 ` Christoph Anton Mitterer
2010-07-25 15:28 ` Arno Wagner
2010-07-25 18:11 ` Milan Broz
2010-07-26 9:04 ` Mario 'BitKoenig' Holbe
2010-07-27 18:21 ` Christoph Anton Mitterer
2010-07-27 21:02 ` Mario 'BitKoenig' Holbe
2010-07-26 9:17 ` Mario 'BitKoenig' Holbe
2010-07-27 18:42 ` David Santamaría Rogado
-- strict thread matches above, loose matches on Subject: below --
2010-07-25 22:25 Ietf Nist
2010-07-25 22:41 ` Christoph Anton Mitterer
2010-07-26 21:07 Arno Wagner
2010-07-26 21:31 ` Christoph Anton Mitterer
2010-07-26 21:45 ` Arno Wagner
2010-07-26 21:42 ` Christoph Anton Mitterer
2010-07-26 22:55 ` Arno Wagner
2010-07-26 23:42 ` Mario 'BitKoenig' Holbe
2010-07-27 10:21 ` Arno Wagner
2010-08-15 17:26 ` Uwe Menges
2010-08-15 22:10 ` Arno Wagner
2010-08-16 11:44 ` Mario 'BitKoenig' Holbe
2010-08-16 12:39 ` Arno Wagner
2010-08-16 12:55 ` octane indice
2010-08-16 14:21 ` Arno Wagner
2010-08-21 20:45 ` Christoph Anton Mitterer
2010-08-21 23:14 ` Arno Wagner
2010-08-22 0:46 ` Christoph Anton Mitterer
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=1280177263.3266.120.camel@fermat.scientia.net \
--to=christoph.anton.mitterer@physik.uni-muenchen.de \
--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.