Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 '. 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
> 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 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@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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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. --- 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 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: --- r...@solaris11:~# zfs send -p mypool/sec...@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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
> "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) 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. pgpogmN8mbJjZ.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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_checksum_deduplicate_with Is there a URL describing the on-disk format and implementation details? It is a work in progress. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
> 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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_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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
> "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 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. pgphDwX1ujOx9.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 > > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 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/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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... http://www.staples.com/sbd/cre/marketing/easybutton/index.html -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 > > 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
> 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 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 > ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS Crypto in Oracle Solaris 11 Express
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? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
