"Enterprise-class" (eCryptfs!)

Michael Halcrow mike at halcrow.us
Thu Aug 11 13:24:14 MDT 2005

On Thu, Aug 11, 2005 at 01:52:07PM -0400, JStay at mediageneral.com wrote:
> I've never really understood the definition of "Enterprise-class"
> either.  I think it means being extremely scalable, the ability to
> span across multiple servers in multiple locations (geographically),
> and the ability for multiple other systems to communicate with each
> other.  Am I wrong on this?  What is the exact definition of
> "Enterprise-class"?

I struggled a bit with this too. When naming my cryptographic
filesystem, I had to find some way to differentiate between it and its
predecessor, Cryptfs. In the grand tradition of modern technology, I
decided to put a letter in front of it. So then I narrowed my options
down to xCryptfs (Extended Cryptfs), iCryptfs (too Mac-like, and I
couldn't think of a good word that starts with 'i'), or eCryptfs
(Enterprise Cryptfs). Hmmmmm. After thinking for a while about the
design goals and the target for the filesystem, I figured that
``Enterprise'' wasn't a bad fit (see p. 209):


When deploying technology for an enterprise environment, there are
certain assumptions that one can make in terms of requirements and
resources. For example, there is likely to be an IT department. There
are also likely to be a large number of systems that require a
consistent set of policies among them. Hence, you have the components
for a framework of some sort -- technologies like Kerberos, LDAP, or
PKI come to mind. My filesystem is designed to be able to leverage
such a framework in order to provide functionality that enables
corporate policy while utilizing corporate PKI in such a way so as to
be completely transparent to the employees who are using the
filesystem (only the IT folks will ever have to be bothered with the
details). If that ain't ``Enterprise'', I don't know what is.

I elaborate in my paper; go ahead and read it and let me know what you

For those who really have some time to kill, my OLS paper from last
year focuses on ``enterprise'' requirements and is the predecessor for
this year's paper. I did a compare-and-contrast among all of the
various crypto filesystems that were out there at the time (it's a bit
outdated now; several filesystems -- i.e., EncFS -- have adopted some
of my suggestions since then) and discusses how they fit into
enterprise environments:


Of course, I will be the first to say that ``Enterprise'' refers to
intended deployment target based on its set of features more than
anything. It still has several months before I would say that it is as
robust as, say, dm-crypt. But then again, it does comprise 14,000
lines of code, 8,000 of which are in the kernel. That's going to take
a little while to fully test and debug across all platforms (x86,
x86-64, PPC, PPC64, s390, s390x, ...). Developers/tested wanted. ;-)


                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769

"This is about humans being human."                                  
 - Carl Sagan 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20050811/dbcbff28/attachment.bin 

More information about the PLUG mailing list