zfs discuss - Nov 2010 - ZFS Crypto in Oracle Solaris 11 Express

Today Oracle Solaris 11 Express was released and is available for 
download[1], this release includes on disk encryption support for ZFS.

Using ZFS encryption support can be as easy as this:

     # zfs create -o encryption=on tank/darren
     Enter passphrase for ''tank/darren'':
     Enter again:
     #

Continued at:

http://blogs.sun.com/darren/entry/introducing_zfs_crypto_in_oracle
http://blogs.sun.com/darren/entry/assued_delete_with_zfs_dataset
http://blogs.sun.com/darren/entry/compress_encrypt_checksum_deduplicate_with

[1] 
http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html

-- 
Darren J Moffat

On Mon, November 15, 2010 14:14, Darren J Moffat wrote:
> Today Oracle Solaris 11 Express was released and is available for
> download[1], this release includes on disk encryption support for ZFS.
>
> Using ZFS encryption support can be as easy as this:
>
>      # zfs create -o encryption=on tank/darren
>      Enter passphrase for ''tank/darren'':
>      Enter again:
Looking forwarding to playing with it. Some questions:
 1. Is it possible to do a ''zfs create -o encryption=off
tank/darren/music'' after the above command? I don''t much care
if my MP3s
are encrypted. :)
 2. Both CCM and GCM modes of operation are supported: can you recommended
which mode should be used when? I''m guessing it''s best to
accept the
default if you''re not sure, but what if we want to expand our
knowledge?

On 11/15/10 19:36, David Magda wrote:
> On Mon, November 15, 2010 14:14, Darren J Moffat wrote:
>> Today Oracle Solaris 11 Express was released and is available for
>> download[1], this release includes on disk encryption support for ZFS.
>>
>> Using ZFS encryption support can be as easy as this:
>>
>>       # zfs create -o encryption=on tank/darren
>>       Enter passphrase for ''tank/darren'':
>>       Enter again:
>
> Looking forwarding to playing with it. Some questions:
>   1. Is it possible to do a ''zfs create -o encryption=off
> tank/darren/music'' after the above command? I don''t much
care if my MP3s
> are encrypted. :)
No, all child filesystems must be encrypted as well.  This is to avoid 
problems with mounting during boot / pool import.  It is possible this 
could be relaxed in the future but it is highly dependent on some other 
things that may not work out.
>   2. Both CCM and GCM modes of operation are supported: can you recommended
> which mode should be used when? I''m guessing it''s best to
accept the
> default if you''re not sure, but what if we want to expand our
knowledge?
You''ve preempted my next planned posting ;-)  But I''ll attempt
to give
an answer here:

''on'' maps to aes-128-ccm, because it is the fastest of the 6
available
modes of encryption currently provided.  Also I believe it is the 
current wisdom of cryptographers (which I do not claim to be) that AES 
128 is the preferred key length due to recent discoveries about AES 256 
that are not know to impact AES 128.

Both CCM[1] and GCM[2] are provided so that if one turns out to have 
flaws hopefully the other will still be available for use safely even 
though they are roughly similar styles of modes.

On systems without hardware/cpu support for Galios multiplication (Intel 
Westmere and later and SPARC T3 and later) GCM will be slower because 
the Galios field multiplication has to happen in software without any 
hardware/cpu assist.  However depending on your workload you might not 
even notice the difference.

One reason you may want to select aes-128-gcm rather than aes-128-ccm is 
that GCM is one of the modes for AES in NSA Suite B[3], but CCM is not.

Are there symmetric algorithms other than AES that are of interest ?
The wrapping key algorithm currently matches the data encryption key 
algorithm, is there interest in providing different wrapping key 
algorithms and configuration properties for selecting which one ?  For 
example doing key wrapping with an RSA keypair/certificate ?

[1] http://en.wikipedia.org/wiki/CCM_mode
[2] http://en.wikipedia.org/wiki/Galois/Counter_Mode
[3] http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography

-- 
Darren J Moffat

On Nov 15, 2010, at 14:36, David Magda wrote:
>
> Looking forwarding to playing with it. Some questions:
> 1. Is it possible to do a ''zfs create -o encryption=off
> tank/darren/music'' after the above command? I don''t much
care if my
> MP3s
> are encrypted. :)
> 2. Both CCM and GCM modes of operation are supported: can you  
> recommended
> which mode should be used when? I''m guessing it''s best to
accept the
> default if you''re not sure, but what if we want to expand our  
> knowledge?
For (2), just posted:

http://blogs.sun.com/darren/entry/choosing_a_value_for_the

Darren J Moffat <darrenm at opensolaris.org> writes:
> On 11/15/10 19:36, David Magda wrote:
>
>>> Using ZFS encryption support can be as easy as this:
>>>
>>>       # zfs create -o encryption=on tank/darren
>>>       Enter passphrase for ''tank/darren'':
>>>       Enter again:
>>
>
>
>>   2. Both CCM and GCM modes of operation are supported: can you
recommended
>> which mode should be used when? I''m guessing it''s
best to accept the
>> default if you''re not sure, but what if we want to expand our
knowledge?
>
> You''ve preempted my next planned posting ;-)  But I''ll
attempt to give
> an answer here:
>
> ''on'' maps to aes-128-ccm, because it is the fastest of
the 6 available
> modes of encryption currently provided.  Also I believe it is the
> current wisdom of cryptographers (which I do not claim to be) that AES
> 128 is the preferred key length due to recent discoveries about AES
> 256 that are not know to impact AES 128.
>
> Both CCM[1] and GCM[2] are provided so that if one turns out to have
> flaws hopefully the other will still be available for use safely even
> though they are roughly similar styles of modes.
>
> On systems without hardware/cpu support for Galios multiplication
> (Intel Westmere and later and SPARC T3 and later) GCM will be slower
> because the Galios field multiplication has to happen in software
> without any hardware/cpu assist.  However depending on your workload
> you might not even notice the difference.
>
> One reason you may want to select aes-128-gcm rather than aes-128-ccm
> is that GCM is one of the modes for AES in NSA Suite B[3], but CCM is
> not.
>
> Are there symmetric algorithms other than AES that are of interest ?
> The wrapping key algorithm currently matches the data encryption key
> algorithm, is there interest in providing different wrapping key
> algorithms and configuration properties for selecting which one ?  For
> example doing key wrapping with an RSA keypair/certificate ?
>
> [1] http://en.wikipedia.org/wiki/CCM_mode
> [2] http://en.wikipedia.org/wiki/Galois/Counter_Mode
> [3] http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography
I appreciate all the hard work the ZFS team and yourself have done to
making this happen. I think a lot of people are going to give this a try
but I noticed that one of the license restrictions was not to run
benchmarks without prior permission from Oracle.  Is Oracle going to
post some benchmarks that might give people an idea of the performance
using the various key lengths? Or even the performance benefit of using
the newer processors with hardware support?

I think a few graphs and testing procedures would be great this might be
an opportunity to convince people the benefit of using sparc and Oracle
hardware while at the same time giving people a basic idea what it could
do for them on their own systems. I would also go as far as saying that
some people would not even know how to setup a baseline to get
comparative test results while using encryption.

I could imagine a lot of people are curious about every aspect of
performance and are thinking is ZFS encryption ready
for production. I just think that some people might need that little
extra nudge that a few graphs and test would provide. If it happens to
also come with a few good practices you could save a lot of people some
time and heart ache as I am sure people are desirous to see the results.

Rthoreau

On Nov 16, 2010, at 2:03 PM, Rthoreau <r7h0re4 at att.net> wrote:
> Darren J Moffat <darrenm at opensolaris.org> writes:
> 
>> On 11/15/10 19:36, David Magda wrote:
>> 
>>>> Using ZFS encryption support can be as easy as this:
>>>> 
>>>>      # zfs create -o encryption=on tank/darren
>>>>      Enter passphrase for ''tank/darren'':
>>>>      Enter again:
>>> 
>> 
>> 
>>>  2. Both CCM and GCM modes of operation are supported: can you
recommended
>>> which mode should be used when? I''m guessing it''s
best to accept the
>>> default if you''re not sure, but what if we want to expand
our knowledge?
>> 
>> You''ve preempted my next planned posting ;-)  But
I''ll attempt to give
>> an answer here:
>> 
>> ''on'' maps to aes-128-ccm, because it is the fastest
of the 6 available
>> modes of encryption currently provided.  Also I believe it is the
>> current wisdom of cryptographers (which I do not claim to be) that AES
>> 128 is the preferred key length due to recent discoveries about AES
>> 256 that are not know to impact AES 128.
>> 
>> Both CCM[1] and GCM[2] are provided so that if one turns out to have
>> flaws hopefully the other will still be available for use safely even
>> though they are roughly similar styles of modes.
>> 
>> On systems without hardware/cpu support for Galios multiplication
>> (Intel Westmere and later and SPARC T3 and later) GCM will be slower
>> because the Galios field multiplication has to happen in software
>> without any hardware/cpu assist.  However depending on your workload
>> you might not even notice the difference.
>> 
>> One reason you may want to select aes-128-gcm rather than aes-128-ccm
>> is that GCM is one of the modes for AES in NSA Suite B[3], but CCM is
>> not.
>> 
>> Are there symmetric algorithms other than AES that are of interest ?
>> The wrapping key algorithm currently matches the data encryption key
>> algorithm, is there interest in providing different wrapping key
>> algorithms and configuration properties for selecting which one ?  For
>> example doing key wrapping with an RSA keypair/certificate ?
>> 
>> [1] http://en.wikipedia.org/wiki/CCM_mode
>> [2] http://en.wikipedia.org/wiki/Galois/Counter_Mode
>> [3] http://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography
> 
> I appreciate all the hard work the ZFS team and yourself have done to
> making this happen. I think a lot of people are going to give this a try
> but I noticed that one of the license restrictions was not to run
> benchmarks without prior permission from Oracle.
This is industry standard faire. Sun had similar restrictions.
>  Is Oracle going to
> post some benchmarks that might give people an idea of the performance
> using the various key lengths? Or even the performance benefit of using
> the newer processors with hardware support?
Good question...
> I think a few graphs and testing procedures would be great this might be
> an opportunity to convince people the benefit of using sparc and Oracle
> hardware while at the same time giving people a basic idea what it could
> do for them on their own systems. I would also go as far as saying that
> some people would not even know how to setup a baseline to get
> comparative test results while using encryption.
> 
> I could imagine a lot of people are curious about every aspect of
> performance and are thinking is ZFS encryption ready
> for production.
Does Oracle "support" Solaris 11 Express in production systems?
> I just think that some people might need that little
> extra nudge that a few graphs and test would provide. If it happens to
> also come with a few good practices you could save a lot of people some
> time and heart ache as I am sure people are desirous to see the results.
I think people are putting encryption in their apps directly (eg
Oracle''s
Transparent Data Encryption feature)
 -- richard
>

> Does Oracle "support" Solaris 11 Express in production systems?
> -- richard
Yes, You need Premier support plan from Oracle for that.
Afaik, sol11 express is production ready, and is going to be updated to real
Solaris 11, and is supported even with non-oracle hardware if you have the money
(and certified system).

Yours
Markus Kovero

On Wed, Nov 17, 2010 at 7:34 PM, Richard Elling <richard.elling at
gmail.com>wrote:
> On Nov 16, 2010, at 2:03 PM, Rthoreau <r7h0re4 at att.net> wrote:
>
>
> > I just think that some people might need that little
> > extra nudge that a few graphs and test would provide. If it happens to
> > also come with a few good practices you could save a lot of people
some
> > time and heart ache as I am sure people are desirous to see the
results.
>
> I think people are putting encryption in their apps directly (eg
Oracle''s
> Transparent Data Encryption feature)
>  -- richard
>

I know there are far more apps without support for encryption than with it.
 And given the ever more stringent government regulations in the US, there
are plenty of customers chomping at the bit for encryption at the storage
array.

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101117/bda1088d/attachment.html>

On Nov 17, 2010, at 1:57 AM, Tim Cook <tim at cook.ms> wrote:
> 
> 
> On Wed, Nov 17, 2010 at 7:34 PM, Richard Elling <richard.elling at
gmail.com> wrote:
> On Nov 16, 2010, at 2:03 PM, Rthoreau <r7h0re4 at att.net> wrote:
> 
> 
> > I just think that some people might need that little
> > extra nudge that a few graphs and test would provide. If it happens to
> > also come with a few good practices you could save a lot of people
some
> > time and heart ache as I am sure people are desirous to see the
results.
> 
> I think people are putting encryption in their apps directly (eg
Oracle''s
> Transparent Data Encryption feature)
>  -- richard
> 
> 
> I know there are far more apps without support for encryption than with it.
And given the ever more stringent government regulations in the US, there are
plenty of customers chomping at the bit for encryption at the storage array.
I do not disagree. There are many products in the market that
"seamlessly" encrypt data. But, vi has had encryption for almost
30 years, so there is clearly no barrier to app writers. As more
development moves to the cloud, encryption comes almost free
at the app layer. The only thing left is the legacy apps...
 -- richard
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101117/7f0a769a/attachment-0001.html>

On 17/11/2010 10:17, Richard Elling wrote:
>> I know there are far more apps without support for encryption than
>> with it. And given the ever more stringent government regulations in
>> the US, there are plenty of customers chomping at the bit for
>> encryption at the storage array.
>
> I do not disagree. There are many products in the market that
> "seamlessly" encrypt data. But, vi has had encryption for almost
> 30 years, so there is clearly no barrier to app writers. As more
> development moves to the cloud, encryption comes almost free
> at the app layer. The only thing left is the legacy apps...
Encryption at the application layer solves a different set of problems 
to encryption at the storage layer.  Just like the encryption in ZFS 
solves a different set of problems to full disk encryption in the drive 
firmware.

These sets have overlapping regions and depending on security policies 
one or more may be the best solution.

As always "encryption" is the "easy" part it is key
management that is
hard, because key management enters the real of policy and key 
management can be hard to scale out to large numbers of apps.

There is on one "correct" solution for where to do encryption just
like
there is on one correct way to write files onto persistent media. 
Choice is important and sometimes choosing more than one is the correct 
thing to do.

-- 
Darren J Moffat

On 11/17/2010 2:33 AM, Darren J Moffat wrote:
> On 17/11/2010 10:17, Richard Elling wrote:
>>> I know there are far more apps without support for encryption than
>>> with it. And given the ever more stringent government regulations
in
>>> the US, there are plenty of customers chomping at the bit for
>>> encryption at the storage array.
>>
>> I do not disagree. There are many products in the market that
>> "seamlessly" encrypt data. But, vi has had encryption for
almost
>> 30 years, so there is clearly no barrier to app writers. As more
>> development moves to the cloud, encryption comes almost free
>> at the app layer. The only thing left is the legacy apps...
>
> Encryption at the application layer solves a different set of problems 
> to encryption at the storage layer.  Just like the encryption in ZFS 
> solves a different set of problems to full disk encryption in the 
> drive firmware.
>
> These sets have overlapping regions and depending on security policies 
> one or more may be the best solution.
>
> As always "encryption" is the "easy" part it is key
management that is
> hard, because key management enters the real of policy and key 
> management can be hard to scale out to large numbers of apps.
>
> There is on one "correct" solution for where to do encryption
just
> like there is on one correct way to write files onto persistent media. 
> Choice is important and sometimes choosing more than one is the 
> correct thing to do.
>
I''m assuming you meant "no" the two times you wrote
"on" in that
second-to-last sentence.  :-)

Actually, I''m just waiting for Staples to come up with a nice big EASY 
button so I can solve all my encryption issues at once...

<wink>

http://www.staples.com/sbd/cre/marketing/easybutton/index.html




-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

On 17/11/2010 11:41, Erik Trimble wrote:
>> There is on one "correct" solution for where to do encryption
just
>> like there is on one correct way to write files onto persistent media.
>> Choice is important and sometimes choosing more than one is the
>> correct thing to do.
>>
> I''m assuming you meant "no" the two times you wrote
"on" in that
> second-to-last sentence. :-)
Yes thanks, it should have read:

There is no one "correct" solution for where to do encryption just
like there is no one correct way to write files onto persistent media.
Choice is important and sometimes choosing more than one is the
correct thing to do.

-- 
Darren J Moffat

On Wed, 17 Nov 2010, Markus Kovero wrote:
>> Does Oracle "support" Solaris 11 Express in production
systems?
>> -- richard
>
> Yes, You need Premier support plan from Oracle for that.
> Afaik, sol11 express is production ready, and is going to be updated 
> to real Solaris 11, and is supported even with non-oracle hardware 
> if you have the money (and certified system).
Solaris 11 Express may be "production ready" but is Oracle Premier 
Support prepared to support it in production?  That seems like the 
vital question to me.  As for myself, I will wait a while and observe 
before assigning my trust.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

On 17/11/2010 14:18, Bob Friesenhahn wrote:
> On Wed, 17 Nov 2010, Markus Kovero wrote:
>
>>> Does Oracle "support" Solaris 11 Express in production
systems?
>>> -- richard
>>
>> Yes, You need Premier support plan from Oracle for that.
>> Afaik, sol11 express is production ready, and is going to be updated
>> to real Solaris 11, and is supported even with non-oracle hardware if
>> you have the money (and certified system).
>
> Solaris 11 Express may be "production ready" but is Oracle
Premier
> Support prepared to support it in production? That seems like the vital
> question to me. As for myself, I will wait a while and observe before
> assigning my trust.
 From the FAQ[1] linked from here:

http://www.oracle.com/technetwork/server-storage/solaris11/overview/index.html


Licensing and Support for Oracle Solaris 11
Express

11-Can I get support for Oracle Solaris 11 Express?

Yes. Oracle Solaris 11 Express is covered under the Oracle
Premier Support for Operating Systems or Oracle Premier
Support for Systems support option for Oracle hardware, and
Oracle Solaris Premier Subscription for non-Oracle
hardware. Customers must choose either of these support
options should they wish to deploy Oracle Solaris 11 Express
into a production environment.

[1] 
http://www.oracle.com/technetwork/server-storage/solaris11/overview/faqs-oraclesolaris11express-185609.pdf

-- 
Darren J Moffat

On Wed, Nov 17, 2010 at 2:18 PM, Bob Friesenhahn
<bfriesen at simple.dallas.tx.us> wrote:
>
> Solaris 11 Express may be "production ready" but is Oracle
Premier Support
> prepared to support it in production?
Right there on the first page for S11 express on Oracle''s web site it
says
"fully tested and supported", and it''s reasonably clear that
the way to
get support is via the existing Premier Support offering. And it''s just
the
same deal as with S10 - you want to use it in production, you need to
have a support contract. It''s not hard to find this out, just a few
seconds
to look at the website.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

On Wed, 17 Nov 2010, Peter Tribble wrote:
>> Solaris 11 Express may be "production ready" but is Oracle
Premier Support
>> prepared to support it in production?
>
> Right there on the first page for S11 express on Oracle''s web site
it says
> "fully tested and supported", and it''s reasonably clear
that the way to
> get support is via the existing Premier Support offering. And it''s
just the
> same deal as with S10 - you want to use it in production, you need to
> have a support contract. It''s not hard to find this out, just a
few seconds
> to look at the website.
I don''t think that looking at a web site can illustrate to me that 
Oracle Premier Support is prepared to support the product in 
production.  The web site only illustrates current intent, not 
ability.  There is indeed a difference.  This is the company which is 
not even prepared to send me a receipt/certificate for my support 
contract and is in process of transitioning to a radically new support 
web infrastructure (based on the Adobe Flash browser plugin) and 
database.  So I will wait a quarter or so before trusting that the 
support function really works.  At the moment I distrust my ability to 
obtain support for even Solaris 10 issues.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

The question that has occurred to me is:

I *must* choose one of those support options for how long?

I mean if I buy support for a machine for a year and put S11 Express
in production on it, then I don''t renew the support, am I now
violating the license?

That''s bogus. I could be wrong but I don''t think Sun ever did
this. As
far as I knew when I worked at Sun, I seem to remember that buying a
machine gave you a ''right to use'' Solaris (even future
versions as I
understood it) on that machine with out any extra charge.

Is there an option to just buy a license outright without paying for
support?

This is as bad a some application software companies are. license
ends  app stops running.
Actually this is worse since it''s not just one app it''s the
whole OS.
At least it doesn''t refuse to run or cripple itself like some other OS
does. ;)

  -Kyle
> Licensing and Support for Oracle Solaris 11 Express
>
> 11-Can I get support for Oracle Solaris 11 Express?
>
> Yes. Oracle Solaris 11 Express is covered under the Oracle Premier
> Support for Operating Systems or Oracle Premier Support for Systems
> support option for Oracle hardware, and Oracle Solaris Premier
> Subscription for non-Oracle hardware. Customers must choose either
> of these support options should they wish to deploy Oracle Solaris
> 11 Express into a production environment.
>
> [1]
>
http://www.oracle.com/technetwork/server-storage/solaris11/overview/faqs-oraclesolaris11express-185609.pdf
>
>

>>>>> "djm" == Darren J Moffat <darrenm at
opensolaris.org> writes:
   djm> http://blogs.sun.com/darren/entry/introducing_zfs_crypto_in_oracle
   djm> http://blogs.sun.com/darren/entry/assued_delete_with_zfs_dataset
   djm>
http://blogs.sun.com/darren/entry/compress_encrypt_checksum_deduplicate_with

Is there a URL describing the on-disk format and implementation details?

   djm> Encryption at the application layer solves a different set of
   djm> problems to encryption at the storage layer. 

black-box crypto is snake oil at any level, IMNSHO.

Congrats again on finishing your project, but every other disk
encryption framework I''ve seen taken remotely seriously has a detailed
paper describing the algorithm, not just a list of features and a
configuration guide.  It should be a requirement for anything treated
as more than a toy.  I might have missed yours, or maybe it''s coming
soon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101117/23307018/attachment.bin>

On 11/17/10 12:04, Miles Nordin wrote:
> black-box crypto is snake oil at any level, IMNSHO.
Absolutely.
> Congrats again on finishing your project, but every other disk
> encryption framework I''ve seen taken remotely seriously has a
detailed
> paper describing the algorithm, not just a list of features and a
> configuration guide.  It should be a requirement for anything treated
> as more than a toy.  I might have missed yours, or maybe it''s
coming
> soon.
In particular, the mechanism by which dedup-friendly block IV''s are 
chosen based on the plaintext needs public scrutiny.  Knowing Darren, 
it''s very likely that he got it right, but in crypto, all the details 
matter and if a spec detailed enough to allow for interoperability
isn''t
available, it''s safest to assume that some of the details are wrong.

						- Bill

On 11/17/10 12:04 PM, Miles Nordin wrote:
>>>>>> "djm" == Darren J Moffat<darrenm at
opensolaris.org>  writes:
>
>     djm> 
http://blogs.sun.com/darren/entry/introducing_zfs_crypto_in_oracle
>     djm> 
http://blogs.sun.com/darren/entry/assued_delete_with_zfs_dataset
>     djm> 
http://blogs.sun.com/darren/entry/compress_encrypt_checksum_deduplicate_with
>
> Is there a URL describing the on-disk format and implementation details?
>
>     djm>  Encryption at the application layer solves a different set of
>     djm>  problems to encryption at the storage layer.
>
> black-box crypto is snake oil at any level, IMNSHO.
That sentence you quote was part of a theoretical discussion of where 
encryption should live, not about whether he or anyone else would share 
implementation details.
> Congrats again on finishing your project, but every other disk
> encryption framework I''ve seen taken remotely seriously has a
detailed
> paper describing the algorithm, not just a list of features and a
> configuration guide.  It should be a requirement for anything treated
> as more than a toy.  I might have missed yours, or maybe it''s
coming
> soon.
Ugh, we all know that the first rule of crytpo is that any proprietary, closed 
source, "black-box" crypto is crap, blah, blah, blah (I am not sure
what the
point of repeating that tired line is) and I am not one to give Oracle an inch 
but wtf? They just released this crap, give them a minute - if anything we 
have seen so far from Oracle shows us is that they are slow to move with 
external communication about Solaris.

> One reason you may want to select aes-128-gcm rather than aes-128-ccm is
> that GCM is one of the modes for AES in NSA Suite B[3], but CCM is not.
> Are there symmetric algorithms other than AES that are of interest ?
How might AES-XTS [1] be able to fit into the the ZFS picture?

Additionally given the user may wish to trade off compression, dedup,
the number of encryptable blocks [2], etc for any particular selectable
algorithm.

[1] http://en.wikipedia.org/wiki/Disk_encryption_theory#XTS
[2] Perhaps handled similar to:
http://groups.google.com/group/mailing.freebsd.security/browse_thread/thread/66d84fdbcee78fcf

On 17/11/2010 20:04, Miles Nordin wrote:
>>>>>> "djm" == Darren J Moffat<darrenm at
opensolaris.org>  writes:
>
>     djm> 
http://blogs.sun.com/darren/entry/introducing_zfs_crypto_in_oracle
>     djm> 
http://blogs.sun.com/darren/entry/assued_delete_with_zfs_dataset
>     djm> 
http://blogs.sun.com/darren/entry/compress_encrypt_checksum_deduplicate_with
>
> Is there a URL describing the on-disk format and implementation details?
It is a work in progress.

-- 
Darren J Moffat

On 18/11/2010 03:55, grarpamp wrote:
>> One reason you may want to select aes-128-gcm rather than aes-128-ccm
is
>> that GCM is one of the modes for AES in NSA Suite B[3], but CCM is not.
>
>> Are there symmetric algorithms other than AES that are of interest ?
>
> How might AES-XTS [1] be able to fit into the the ZFS picture?
It doesn''t.  We don''t need it because we don''t need
to have the
ciphertext the same size as the plaintext because we have space to store 
a sufficiently large MAC (and store an IV as well).  This is why CCM and 
GCM were chosen rather than XTS or EME2.
> Additionally given the user may wish to trade off compression, dedup,
> the number of encryptable blocks [2], etc for any particular selectable
> algorithm.
We don''t need to make those compromises in ZFS, you can compress and 
encrypt and dedup (it happens in that order).

http://blogs.sun.com/darren/entry/compress_encrypt_checksum_deduplicate_with

For changing the encryption key see the discussion of ''zfs key
-K'' in
the zfs(1M) man page:

http://docs.sun.com/app/docs/doc/821-1462/zfs-1m?l=en&a=view

-- 
Darren J Moffat

>>>>> "zu" == zfs user <zfsml at
itsbeen.sent.com> writes:
>>>>> "djm" == Darren J Moffat <darrenm at
opensolaris.org> writes:
    zu> Ugh, we all know that the first rule of crytpo is that any
    zu> proprietary, closed source, "black-box" crypto is crap,
blah,
    zu> blah, blah (I am not sure what the point of repeating that
    zu> tired line is) and I am not one to give Oracle an inch but
    zu> wtf? They just released this crap, give them a minute

My educated guess would be that the other encrypted systems released
papers about the algorithm either concurrently with the
implementation, or sometimes BEFORE the implementation, but not after.
It''s just silly to think geli or dmcrypt would expect anyone to use
them without explaining the algorithm and exposing it to review.

Also, Darren has been working on this for THREE YEARS, and he
committed it just weeks after the ``opensolaris now closed''''
announcement and hg pushing stopped.  so, any time in the last three
years would have been a better and more reasonable time to release a
paper than tomorrow, after the binary proprietary release of the
implementation has happened.  This would eliminate the need for my
objection as well as give the crypto community time to advise Darren''s
design, which is something I''m surprised he didn''t want as
much of as
possible, but so be it: he''s the one doing the work, and good for him,
and since based on hints he''s dropped I suspect the work is quite
good, I''m more interested in reviewing the work that''s there
than
whinging about preciesly how it was done or how long it took or when I
can get it.  For all that, I''ll gladly wait.

I just think firstly that the design needs review before trust, and
secondly that it''s starkly enough against best practice to be
borderline irresponsible to release the work at all without subjecting
the design to peer review.

    zu> anything we have seen so far from Oracle shows us is that they
    zu> are slow to move with external communication about Solaris.

yeah, well.  what happened after you ``waited'''' last time?

When people like me were saying ``not all of opensolaris is free
software.  In fact the free component is shockingly small, albeit an
important component,'''' and ``the full development cycle from
hg to
livecd needs to be freed, like it is on *BSD (build.sh) and RHEL
(CentOS), so that the project can be forked if, god forbid, it needs
to be---forking is bad, but forkability is a key component of
freedom,'''' and ``it is a problem that the toolchain is
proprietary'''',
people like you said ``just give them time.''''  I think we
actually did
quietly get a few big chunks liberated just by waiting, but still, in
the end, you gave them too much time: openindiana and illumos are now
struggling to solve parts of these problems without certainty of
success, are rushed because Nexenta''s business depends on them, and
people who have invested in the platform thinking its freedom gave it
a stable future are now sitting on many terabytes of locked-in data
and many man-hours of doomed scriptage.  While the disaster is
certainly not complete and some gradual-transition outcomes remain
possible, your ``give them time'''' advice is basically dead
wrong,
according to history.  How can you say that now?  I don''t get it.

Finally, there''s a problem with the style of argument.  Not everything
on a mailing list is ``$ENTITY sucks/rules.''''  I''m
allowed to say
something critical without implicitly saying ``everything Oracle does
and everything they touch is wrong and evil and should be burned with
torches.''''  I don''t really care about Oracle at all. 
What I said was
much more specific, and there''s no cause to wait before saying ``I
will not take zfs crypto seriously so long as it''s a black
box.''''  The
right time to say that is NOW.

so, no, I disagree: do not give them time.  Wait for the paper, or
more likely for the actual source, before using ZFS crypto.  That is
what you should do with your Time.

   djm> It is a work in progress.

Fine, and good.  I thought it might be.  

In the unlikely event there was any impediment to your writing, and
releasing, the paper, hopefully my complaining will be one among many
things that helps remove it.  Really, it is just mandatory.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101118/1a1446b1/attachment-0001.bin>

On Thu, 18 Nov 2010, Miles Nordin wrote:
> In the unlikely event there was any impediment to your writing, and
> releasing, the paper, hopefully my complaining will be one among many
> things that helps remove it.  Really, it is just mandatory.
Thanks for removing your impediment.  The world will be a much better 
place because of your action.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

On Nov 16, 2010, at 05:09, Darren J Moffat wrote:
> Both CCM[1] and GCM[2] are provided so that if one turns out to have  
> flaws hopefully the other will still be available for use safely  
> even though they are roughly similar styles of modes.
>
> On systems without hardware/cpu support for Galios multiplication  
> (Intel Westmere and later and SPARC T3 and later) GCM will be slower  
> because the Galios field multiplication has to happen in software  
> without any hardware/cpu assist.  However depending on your workload  
> you might not even notice the difference.
Both modes of operation are authenticating. At one point the design of  
ZFS crypto had the checksum automatically go to SHA-256 when it was  
enabled. [1] Is "SHA activation" still the case, or are the two modes
of operations simply used in themselves to verify data integrity?

Also, are slog and cache devices encrypted at this time? Given a pool,  
and the fact that only particular data sets on it could be encrypted,  
would these special devices be entirely encrypted, or only data from  
the particular encrypted data set/s? I would also assume the in-memory  
ARC would be clear-text.

[1] http://tinyurl.com/2asc3y5
[1]
http://arc.opensolaris.org/caselog/PSARC/2007/261/inception.materials/zfs-crypto-design.pdf

On 19/11/2010 00:39, David Magda wrote:
> On Nov 16, 2010, at 05:09, Darren J Moffat wrote:
>
>> Both CCM[1] and GCM[2] are provided so that if one turns out to have
>> flaws hopefully the other will still be available for use safely even
>> though they are roughly similar styles of modes.
>>
>> On systems without hardware/cpu support for Galios multiplication
>> (Intel Westmere and later and SPARC T3 and later) GCM will be slower
>> because the Galios field multiplication has to happen in software
>> without any hardware/cpu assist. However depending on your workload
>> you might not even notice the difference.
>
> Both modes of operation are authenticating. At one point the design of
> ZFS crypto had the checksum automatically go to SHA-256 when it was
> enabled. [1] Is "SHA activation" still the case, or are the two
modes of
> operations simply used in themselves to verify data integrity?
That is still the case, the blockpointer contains the IV, the SHA256 
checksum (truncated) and the MAC from CCM and GCM.
> Also, are slog and cache devices encrypted at this time? Given a pool,
> and the fact that only particular data sets on it could be encrypted,
> would these special devices be entirely encrypted, or only data from the
> particular encrypted data set/s? I would also assume the in-memory ARC
> would be clear-text.
The ZIL wither it is in pool or on a slog is always encrypted for an 
encrypted dataset, it is encrypted in exactly the same way.

Data from encrypted datasets does not currently go to the L2ARC cache 
devices.

The in memory ARC is in the clear and it has to be because those buffers 
can be shared via zero copy means to other parts of the system including 
other filesystems like NFS and CIFS.
-- 
Darren J Moffat

The design for ZFS crypto was done in the open via opensolaris.org and 
versions of the source (though not the final version at this time) are 
available on opensolaris.org.

It was reviewed by internal and external to Sun/Oracle people who have 
considerable crypto experience.  Important parts of the cryptography 
design were also discussed on other archived public forums as well as 
zfs-crypto-discuss.

The design was also presented at IEEE 1619 SISWG and at SNIA.

--
Darren J Moffat

I just tested crypto a little and I have some send/receive specific questions
about it. It would be great if someone could clarify.

Currently ZFS has no background rewriter. However the fact that ZFS applies most
of the properties and tunables (like dedup or compression) on write time for all
newly written data makes send/receive a good (offline) workaround to compress,
decompress or dup/dedup all your data by just doing a local send/receive.

I wanted to test the same thing for crypto. Crypto is a create only propert, so
I can not change it to encrypt or decrypt a existing dataset.

It seems that I can send a encrypted dataset to a unencrypted target. If I send
via -p (to keep the properties), this works also and ZFS asks me for a
passphrase.

When testing the other way around, encrypting existing datasets, I would like to
send a (unencrypted) dataset to a encrypted target set. It seems however that
this is not possible.

---
root at solaris11:~# zfs list mypool/secret_received
cannot open ''mypool/secret_received'': dataset does not exist
root at solaris11:~# zfs send mypool/plaintext at test | zfs receive -o
encryption=on mypool/secret_received
cannot receive: cannot override received encryption
---

Is there a implementation/technical  reason for not allowing this ? 

Based on the tests that "decryption by send/receive" works, I would
assume that "encryption by send/receive" would also be technically
possible ??

Also it seems that I can not "decrypt by send/receive" if I want to
send all other properties:

---
root at solaris11:~# zfs send -p mypool/secret at test | zfs receive -x
encryption mypool/publicneu
cannot receive: cannot override received encryption
---

This looks like a implementation limitation to me, because actually it is the
same as the simple working "non property" send receive  above.

Some clarification on the impact of encryption to send/receive would help. 

Regards, 
Robert
-- 
This message posted from opensolaris.org

On 23/11/2010 21:01, StorageConcepts wrote:
> root at solaris11:~# zfs list mypool/secret_received
> cannot open ''mypool/secret_received'': dataset does not
exist
> root at solaris11:~# zfs send mypool/plaintext at test | zfs receive -o
encryption=on mypool/secret_received
> cannot receive: cannot override received encryption
> ---
>
> Is there a implementation/technical  reason for not allowing this ?
Yes there is, this is because of how the ZPL metadata is written to disk 
- it is slightly different between encrypted and non encrypted cases and 
unfortunately that difference shows up even in the ZFS send stream.

It is a known (and documented in the Admin guide) restriction.

If we allowed the receive to proceed the result would be that some ZPL 
metadata (including filenames) for some files may end up on disk in the 
clear, there are various cases where this could happen but it is most 
likely to happen when the filesystem is being used by Windows clients 
because of the combination of things that happen - but it can equally 
well happen with only local ZPL usage too particularly if there are 
large ACLs in use.

In the mean time the best workaround I can offer is to use 
tar/cpio/rsync, but obviously you lose your snapshot history that way.

-- 
Darren J Moffat

> On 23/11/2010 21:01, StorageConcepts wrote:
> > root at solaris11:~# zfs list mypool/secret_received
> > cannot open ''mypool/secret_received'': dataset does
> not exist
> > root at solaris11:~# zfs send mypool/plaintext at test |
> zfs receive -o encryption=on mypool/secret_received
> > cannot receive: cannot override received encryption
> > ---
> >
> > Is there a implementation/technical  reason for not
> allowing this ?
> 
> Yes there is, this is because of how the ZPL metadata
> is written to disk 
> - it is slightly different between encrypted and non
> encrypted cases and 
> unfortunately that difference shows up even in the
> ZFS send stream.
> 
> It is a known (and documented in the Admin guide)
> restriction.
> 
> If we allowed the receive to proceed the result would
> be that some ZPL 
> metadata (including filenames) for some files may end
> up on disk in the 
> clear, there are various cases where this could
> happen but it is most 
> likely to happen when the filesystem is being used by
> Windows clients 
> because of the combination of things that happen -
> but it can equally 
> well happen with only local ZPL usage too
> particularly if there are 
> large ACLs in use.
> 
> In the mean time the best workaround I can offer is
> to use 
> tar/cpio/rsync, but obviously you lose your snapshot
> history that way.
> 
> -- 
> Darren J Moffat
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discu
> ss
> 

We are also tracking ZFS encryption questions here:

http://hub.opensolaris.org/bin/view/Community+Group+zfs/encrypt

Thanks,

Cindy
-- 
This message posted from opensolaris.org

On Wed, Nov 17, 2010 at 01:58:06PM -0800, Bill Sommerfeld
wrote:
> On 11/17/10 12:04, Miles Nordin wrote:
> >black-box crypto is snake oil at any level, IMNSHO.
> 
> Absolutely.
As Darren said, much of the design has been discussed in public, and
reviewed by cryptographers.  It''d be nicer if we had a detailed paper
though.
> >Congrats again on finishing your project, but every other disk
> >encryption framework I''ve seen taken remotely seriously has a
detailed
> >paper describing the algorithm, not just a list of features and a
> >configuration guide.  It should be a requirement for anything treated
> >as more than a toy.  I might have missed yours, or maybe it''s
coming
> >soon.
> 
> In particular, the mechanism by which dedup-friendly block IV''s
are
> chosen based on the plaintext needs public scrutiny.  Knowing
> Darren, it''s very likely that he got it right, but in crypto, all
> the details matter and if a spec detailed enough to allow for
> interoperability isn''t available, it''s safest to assume
that some of
> the details are wrong.
Dedup + crypto does have security implications.  Specifically: it
facilitates "traffic" analysis, and then known- and even
chosen-plaintext attacks (if there were any practical such attacks on
the cipher).

For example, IIUC, the ratio of dedup vs.  non-dedup blocks + analysis
of dnodes and their data sizes (in blocks) + per-dnode dedup ratios can
probably be used to identify OS images, which would then help mount
known-plaintext attacks.  For a mailstore you''d be able to distinguish
mail sent or kept by a single local user vs. mail sent to and kept by
more than one local user, and by sending mail you could help mount
chose-plaintext attacks.  And so on.

My advice would be to not bother encrypting OS images, and if you
encrypt only documents, then dedup is likely of less or no interest to
you -- in general, you may not want to bother with dedup + crypto.
However, it is fantastic that crypto and dedup can work together.

Nico
--

On 17/11/2010 21:58, Bill Sommerfeld wrote:
> In particular, the mechanism by which dedup-friendly block IV''s
are
> chosen based on the plaintext needs public scrutiny. Knowing Darren,
> it''s very likely that he got it right, but in crypto, all the
details
> matter and if a spec detailed enough to allow for interoperability
isn''t
> available, it''s safest to assume that some of the details are
wrong.
That is described here:

http://blogs.sun.com/darren/entry/zfs_encryption_what_is_on

"If dedup=on for the dataset the per block IVs are generated 
differently.  They are generated by taking an HMAC-SHA256 of the 
plaintext and using the left most 96 bits of that as the IV.  The key 
used for the HMAC-SHA256 is different to the one used by AES for the 
data encryption, but is stored (wrapped) in the same keychain entry, 
just like the data encryption key a new one is generated when doing a 
''zfs key -K <dataset>''.  Obviously we couldn''t
calculate this IV when
doing a read so it has to be stored."

This was also suggested independently by other well known people 
involved in encrypted filesystems while it was discussed on a public 
forum (most of that thread was cross posted to zfs-crypto-discuss).

-- 
Darren J Moffat

Also, when the IV is stored you can more easily look for accidental IV
re-use, and if you can find hash collisions, them you can even cause IV
re-use (if you can write to the filesystem in question).  For GCM IV
re-use is rather fatal (for CCM it''s bad, but IIRC not fatal), so
I''d
not use GCM with dedup either.

Nico
--