From: Milan Broz <gmazyland@gmail.com>
To: dm-crypt@saout.de
Cc: Stavros Kousidis <dabros.kuhsadas@web.de>
Subject: Re: [dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes
Date: Wed, 06 Feb 2013 15:08:00 +0100 [thread overview]
Message-ID: <511263C0.9040700@gmail.com> (raw)
In-Reply-To: <trinity-5e451cd0-1b94-4006-82ec-553bc8d49873-1360157682485@3capp-webde-bs40>
On 02/06/2013 02:34 PM, Stavros Kousidis wrote:
>> But that said, yes I'm very well aware of this problem and I would
>> like to have at least some analysis what's really going on in todays
>> flash storage devices and how it is related to disk encryption security.
>> So let's try to gather some data first.
>
> That clarifies some things to me, and yes, I would also like to know what's happening inside those things. Especially since I have seen:
> http://static.usenix.org/events/fast11/tech/full_papers/Wei.pdf
yes, this is nice paper!
Please if anyone here have more such pointers, please post it here!
I am quite interested in research here and there are several interesting
interactions which surely need more coverage.
>> But do not forget one thing - while cryptsetup is always open to support
>> wide range of algorithms, a huge user base is bound by standards which do not
>> allow them to use anything else. That's why XTS is so widely used.
>
> Ok that sounds reasonable (doable???). What exactly do you mean by a huge user base being bound by standards and to XTS?
I mean users which are required to comply (at least to some extent) to FIPS standards for example.
(Usually government & public sector etc.)
Here, AFAIK, you can use AES and CBC or XTS modes only.
And I am trying to keep default cryptsetup/LUKS modes compatible with these,
but really, that was just note that many people will (or will have to) prefer standard modes
(which get more analysis as well).
Milan
next prev parent reply other threads:[~2013-02-06 14:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.6.1360140726.2399.dm-crypt@saout.de>
2013-02-06 10:06 ` [dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes Stavros Kousidis
2013-02-06 10:32 ` Arno Wagner
2013-02-06 12:52 ` Milan Broz
2013-02-06 13:06 ` Arno Wagner
2013-02-06 11:07 ` Matthias Schniedermeyer
2013-02-06 12:45 ` Arno Wagner
2013-02-06 13:18 ` Stavros Kousidis
2013-02-06 12:38 ` Milan Broz
2013-02-06 13:34 ` Stavros Kousidis
2013-02-06 14:08 ` Milan Broz [this message]
2013-02-06 13:59 ` Stavros Kousidis
2013-02-09 14:20 ` Alex Elsayed
[not found] <mailman.1.1360494001.22742.dm-crypt@saout.de>
2013-02-12 8:47 ` Stavros Kousidis
2013-02-12 12:41 ` Arno Wagner
[not found] <mailman.1.1360148402.2056.dm-crypt@saout.de>
2013-02-06 13:22 ` Stavros Kousidis
2013-02-06 8:52 Stavros Kousidis
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=511263C0.9040700@gmail.com \
--to=gmazyland@gmail.com \
--cc=dabros.kuhsadas@web.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.