From: Lars Marowsky-Bree <lmb@suse.com>
To: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Improving Data-At-Rest encryption in Ceph
Date: Mon, 18 Jan 2016 13:21:16 +0100 [thread overview]
Message-ID: <20160118122116.GH26972@suse.de> (raw)
In-Reply-To: <CAHMeWhHn-8dD_5+1zDizBijwwMZNS7K9ukHk_y_EQQxjKgM88g@mail.gmail.com>
On 2016-01-18T09:05:58, Adam Kupczyk <akupczyk@mirantis.com> wrote:
Hi Adam,
> Plugging this into calculations I was using previously, gives us:
> 1) Dmcrypt:
> 1*0.36+2.5*0.64*3 = 5.16 bytes of crypto operations per byte of io data.
> 2) potential inside OSD encryption
> 1*0.36+1*0.64 = 1 byte of crypto operations per byte of io data.
>
> This further deepens my concern that crypto transformations may be
> limit for performance.
I see your concern, but my primary concern is not about performance,
rather security.
By not encrypting the entire OSD device, one becomes susceptible to
metadata analysis (on the file store), data exposure, etc. (Plus,
obviously, that the system devices need to be encrypted to avoid data
leaks via logs, swap, coredumps etc.)
It doesn't help my use case that your implementation is theoretically
faster if it doesn't fit the threat scenario.
I'd obviously be delighted to see this all sped up (and consume less
power), but as long as the system is fast enough to encrypt at
near-device speeds, this seems preferable.
I'm not opposed to your implementation - I just couldn't sell it to my
customers for data-at-rest encryption.
Regards,
Lars
--
Architect Storage/HA
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-01-18 12:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 13:17 Improving Data-At-Rest encryption in Ceph Radoslaw Zarzynski
2015-12-14 20:28 ` Gregory Farnum
2015-12-14 22:02 ` Martin Millnert
2015-12-14 22:32 ` Gregory Farnum
2015-12-16 2:13 ` Andrew Bartlett
2015-12-15 10:13 ` Adam Kupczyk
2015-12-15 10:04 ` Adam Kupczyk
[not found] ` <CAHMeWhGgHWq=jPZfj8s_KCB=wLhsBNCyJjZSBQQFZXc8r63M7A@mail.gmail.com>
2015-12-15 21:04 ` Gregory Farnum
2015-12-16 15:13 ` Adam Kupczyk
2015-12-16 15:36 ` Radoslaw Zarzynski
2015-12-14 21:52 ` Martin Millnert
2015-12-15 20:40 ` Radoslaw Zarzynski
2015-12-15 14:23 ` Lars Marowsky-Bree
2015-12-15 14:59 ` Sage Weil
2015-12-15 23:31 ` Matt Benjamin
2015-12-16 22:29 ` Adam Kupczyk
2015-12-16 22:33 ` Sage Weil
2015-12-21 8:21 ` Adam Kupczyk
2016-01-18 8:05 ` Adam Kupczyk
2016-01-18 12:21 ` Lars Marowsky-Bree [this message]
2016-01-25 19:05 ` Radoslaw Zarzynski
2016-01-25 22:20 ` Kyle Bader
2016-01-24 13:45 ` John Hunter
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=20160118122116.GH26972@suse.de \
--to=lmb@suse.com \
--cc=ceph-devel@vger.kernel.org \
/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.