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
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
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 ha
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 featu
> On 23/11/2010 21:01, StorageConcepts wrote:
> > r...@solaris11:~# zfs list mypool/secret_received
> > cannot open 'mypool/secret_received': dataset does
> not exist
> > r...@solaris11:~# zfs send mypool/plaint...@test |
> zfs receive -o encryption=on mypool/secret_received
> > cannot receive: can
On 23/11/2010 21:01, StorageConcepts wrote:
r...@solaris11:~# zfs list mypool/secret_received
cannot open 'mypool/secret_received': dataset does not exist
r...@solaris11:~# zfs send mypool/plaint...@test | zfs receive -o encryption=on
mypool/secret_received
cannot receive: cannot override receiv
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 n
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
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 witho
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 mu
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
> "zu" == zfs user writes:
> "djm" == Darren J Moffat 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)
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
On 17/11/2010 20:04, Miles Nordin wrote:
"djm" == Darren J Moffat 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_checks
> 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
On 11/17/10 12:04 PM, Miles Nordin wrote:
"djm" == Darren J Moffat 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_check
> "djm" == Darren J Moffat 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 describi
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
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
On Wed, Nov 17, 2010 at 2:18 PM, Bob Friesenhahn
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 reasonab
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 rea
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
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
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
encryptio
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. Th
On Nov 17, 2010, at 1:57 AM, Tim Cook wrote:
>
>
> On Wed, Nov 17, 2010 at 7:34 PM, Richard Elling
> wrote:
> On Nov 16, 2010, at 2:03 PM, Rthoreau 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
On Wed, Nov 17, 2010 at 7:34 PM, Richard Elling wrote:
> On Nov 16, 2010, at 2:03 PM, Rthoreau 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 lo
> 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 (a
On Nov 16, 2010, at 2:03 PM, Rthoreau wrote:
> Darren J Moffat 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
Darren J Moffat 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 operatio
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 s
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:
# zf
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/d
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:
On 05/10/2010 20:14, Miles Nordin wrote:
I'm glad it wasn't my project, though. If I were in Darren's place
I'd have signed on to work for an open-source company, spent seven
years of my life working on something, delaying it and pushing hard to
make it a generation beyond other filesystem crypt
> "dm" == David Magda writes:
dm> Thank you Mr. Moffat et al. Hopefully the rest of us will be
dm> able to bang on this at some point. :)
Thanks for the heads-up on the gossip.
This etiquette seems weird, though: I don't thank Microsoft for
releasing a new version of Word. I'll p
Seems that the bug for ZFS data set encryption is now in a state of
"10-Fix Delivered":
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4854202
Via:
http://sparcv9.blogspot.com/2010/10/zfs-crypto-integrated.html
Thank you Mr. Moffat et al. Hopefully the rest of us
Deirdre has posted a video of the presentation Darren Muffat gave at
the November 2009 Solaris Security Summit:
http://blogs.sun.com/video/entry/zfs_crypto_data_encryption_for
Slides (470 KB PDF):
http://wikis.sun.com/download/attachments/164725359/osol-sec-sum-09-zfs.pdf
___
On Mon, Dec 21, 2009 at 02:44:00PM -0800, Darren J Moffat wrote:
> The IV generation when doing deduplication
> is done by calculating an HMAC of the plaintext using a separate per
> dataset key (that is also refreshed if 'zfs key -K' is run to rekey the
> dataset).
> [..]
> In the case where
Garrett D'Amore wrote:
[replying off arc]
Hmm that's too bad. I think it would still be preferable for
changes of this nature to get at least some minimal review at ARC.
Although as we don't have any ZFS representation at ARC, maybe review of
such changes wouldn't add anything useful.
I
Darren J Moffat wrote:
Garrett D'Amore wrote:
Darren J Moffat wrote:
Dataset rename restrictions
---
On rename a dataset can non be moved out of its wrapping key hierarchy
ie where it inherits the keysource property from. This is best
explained by example:
# zfs get
Brian Hechinger wrote:
On Tue, Aug 18, 2009 at 12:37:23AM +0100, Robert Milkowski wrote:
Hi Darren,
Thank you for the update.
Have you got any ETA (build number) for the crypto project?
Also, is there any word on if this will support the hardware crypto stuff
That has always been the plan a
Hi,
Brian Hechinger wrote:
On Tue, Aug 18, 2009 at 12:37:23AM +0100, Robert Milkowski wrote:
Hi Darren,
Thank you for the update.
Have you got any ETA (build number) for the crypto project?
Also, is there any word on if this will support the hardware crypto stuff
in the VIA CPUs natively? T
On Tue, Aug 18, 2009 at 12:37:23AM +0100, Robert Milkowski wrote:
> Hi Darren,
>
> Thank you for the update.
> Have you got any ETA (build number) for the crypto project?
Also, is there any word on if this will support the hardware crypto stuff
in the VIA CPUs natively? That would be nice. :)
-
Garrett D'Amore wrote:
Darren J Moffat wrote:
Dataset rename restrictions
---
On rename a dataset can non be moved out of its wrapping key hierarchy
ie where it inherits the keysource property from. This is best
explained by example:
# zfs get -r keysource tankNA
Darren J Moffat wrote:
Dataset rename restrictions
---
On rename a dataset can non be moved out of its wrapping key hierarchy
ie where it inherits the keysource property from. This is best explained
by example:
# zfs get -r keysource tank
NAMEPROPERTY VA
Hi Darren,
Thank you for the update.
Have you got any ETA (build number) for the crypto project?
--
Robert Milkowski
http://milek.blogspot.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-d
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
ZFS Crypto Updates
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Document:
So onnv_111 is no longer the target for crypto integration since that
build is supposed to be included in osol 2009.06?
Regards
Henrik
On 5 mar 2009, at 11.06, Darren J Moffat
wrote:
Luca Morettoni wrote:
A lot of people ask me about crypto layer over ZFS and the future
integration in
Henrik Johansson wrote:
So onnv_111 is no longer the target for crypto integration since that
build is supposed to be included in osol 2009.06?
onnv_111 wasn't the target of record the project page says build 115.
Given some design and codreview discussions we had last week on
interactions be
Luca Morettoni wrote:
A lot of people ask me about crypto layer over ZFS and the future
integration in OpenSolaris (I read around snv_111), it may be ready for
the next stable release (2009.06)?
See:
http://opensolaris.org/os/project/zfs-crypto/
No it won't be in 2009.06. To be in 2009.06 i
A lot of people ask me about crypto layer over ZFS and the future
integration in OpenSolaris (I read around snv_111), it may be ready for
the next stable release (2009.06)?
Thanks and sorry for the cross-post!
--
Luca Morettoni
Web and BLOG @ http://www.morettoni.net/ | OpenSolaris SCA #OS0344
Joe S. Ixpack wrote:
> Hi,
>
> is there a way to use ZFS Encryption with OpenSolaris/Indiana?
At this time no. Well not unless you build the source from the mercurial
source repository yourself.
> I've searching for a roadmap, where will it be integrated first
(opensolaris, solaris CE etc)...
Hi,
is there a way to use ZFS Encryption with OpenSolaris/Indiana? I've searching
for a roadmap, where will it be integrated first (opensolaris, solaris CE
etc)...
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@op
Just a reminder that the ZFS Crypto project is going for PSARC
commitment review this week.
Meeting Details are here:
http://opensolaris.org/os/community/arc/announcements/#2008-01-31_OpenSolaris_ARC_Agenda_for_February_6__2008
Submitted review materials are here:
http://opensolaris.org/os/com
A few things come to mind:
* Attaching a label to the zfs filesystem, so I can't mount the FS in
an unlabeled or differently-labeled zone if I don't want to.
(multiple labels for shared fs's would be cool, too.)
* Connecting the startup of the trusted zone (I'm still learning this
stuff, sorry if I
Lally Singh wrote:
> Looks great.. Any (long-term distant-future) plans of integrating this
> with the Trusted Extensions for a real quick setup?
For you what would "integrated" with Trusted Extensions mean ?
They certainly work together just fine, but I want to better understand
what you are a
Looks great.. Any (long-term distant-future) plans of integrating this with the
Trusted Extensions for a real quick setup? With a check to make sure the key's
password != the label, just to be sure :-P
This message posted from opensolaris.org
___
z
I'm pleased to announce that the ZFS Crypto project now has Alpha
release binaries that you can download and try. Currently we only have
x86/x64 binaries available, SPARC will be available shortly.
Information on the Alpha release of ZFS Crypto and links for downloading
the binaries is here:
All details on how to participate are posted on the review site:
http://opensolaris.org/os/project/zfs-crypto/design_review/
--
Darren J Moffat
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinf
The ZFS Crypto project is nearing completion of the design for phase 1.
A two week design review will be held starting with the publication of
the phase 1 design document on Monday 2nd July. I will also arrange a
1hr conference call to discuss issues interactively.
Details of where to find t
61 matches
Mail list logo
