Re: Committing PEFS to CURRENT
Alexandre Biancalana wrote this message on Fri, Dec 27, 2013 at 17:20 -0200: > On Tue, Oct 8, 2013 at 12:12 AM, Gleb Kurtsou wrote: > > > On (07/10/2013 21:59), Outback Dingo wrote: > > > On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou > > wrote: > > > > > > > On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney > > wrote: > > > > > > > > > > But will the work get done to clean it up after the freeze is over? > > What > > > > > happens if it doesn't, will it get removed before 10.1 or will we > > have > > > > > to live w/ the code? > > > > > > > > I still hope not to get hit by bus any time soon.. > > > > > > > > > > on a side note, i applied the patch to stable/9 out of curiosity and the > > > kernel failed to build the module > > > however i could install fine from ports. > > > > Correct, there is no support for old kernels in the patch. > > Port will be maintained and will provide support for older versions in > > case PEFS finds its way to 10.0. > > Are there any news about PEFS commit ? It's definately not going into 10.0, but it could make it in a future release, but... I haven't heard back about plans for moving forward on the project. I'm definately interested in getting this in the tree, but have other work that is higher priority right now. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Tue, Oct 8, 2013 at 12:12 AM, Gleb Kurtsou wrote: > On (07/10/2013 21:59), Outback Dingo wrote: > > On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou > wrote: > > > > > On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney > wrote: > > > > > > > > But will the work get done to clean it up after the freeze is over? > What > > > > happens if it doesn't, will it get removed before 10.1 or will we > have > > > > to live w/ the code? > > > > > > I still hope not to get hit by bus any time soon.. > > > > > > > on a side note, i applied the patch to stable/9 out of curiosity and the > > kernel failed to build the module > > however i could install fine from ports. > > Correct, there is no support for old kernels in the patch. > Port will be maintained and will provide support for older versions in > case PEFS finds its way to 10.0. Hi, Are there any news about PEFS commit ? Regards, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On (07/10/2013 21:59), Outback Dingo wrote: > On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou wrote: > > > On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney wrote: > > > > > > But will the work get done to clean it up after the freeze is over? What > > > happens if it doesn't, will it get removed before 10.1 or will we have > > > to live w/ the code? > > > > I still hope not to get hit by bus any time soon.. > > > > on a side note, i applied the patch to stable/9 out of curiosity and the > kernel failed to build the module > however i could install fine from ports. Correct, there is no support for old kernels in the patch. Port will be maintained and will provide support for older versions in case PEFS finds its way to 10.0. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou wrote: > On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney wrote: > > > > But will the work get done to clean it up after the freeze is over? What > > happens if it doesn't, will it get removed before 10.1 or will we have > > to live w/ the code? > > I still hope not to get hit by bus any time soon.. > on a side note, i applied the patch to stable/9 out of curiosity and the kernel failed to build the module however i could install fine from ports. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 9:42 PM, Gleb Kurtsou wrote: > On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney wrote: > > > > But will the work get done to clean it up after the freeze is over? What > > happens if it doesn't, will it get removed before 10.1 or will we have > > to live w/ the code? > > I still hope not to get hit by bus any time soon.. > well, i think we all hope you dont get hit by a bus. ever > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 6:24 PM, John-Mark Gurney wrote: > > But will the work get done to clean it up after the freeze is over? What > happens if it doesn't, will it get removed before 10.1 or will we have > to live w/ the code? I still hope not to get hit by bus any time soon.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 17:41 -0700: > On Mon, Oct 7, 2013 at 5:23 PM, John-Mark Gurney wrote: > > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 16:47 -0700: > >> On Mon, Oct 7, 2013 at 4:17 PM, John-Mark Gurney wrote: > >> > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700: > >> >> Patch is available here: > >> >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch > >> > > >> > Is there a reason you are writing your own AES-NI implementation instead > >> > of using the OpenCrypto framework? > >> > >> It reuses the same AES-NI implementation used by opencrypto, > >> but code doesn't use opencrypto directly. Main limitation in opencrypto is > >> that is incomplete implementation AES-XTS -- it doesn't implement > >> ciphertext > >> stealing. opencrypto contexts seemed to be too much overhead list time I > > > > I remember noticing that when I was working on it.. but as there are > > different modes of packing/padding, I decided not to do anything with > > that... > > > > I also don't like your lack of comments arround xts_lastblock and about > > why it is accessing dst - 1... To me, you should pass in the previous > > block as an arg to xts_lastblock instead of doing dst[-1]... You did > > comment what you're doing (m - 1), but not why it is safe to do that... > > There is no comment that you're implementing ciphertext stealing w/ the > > function which makes it even harder to understand that you'd going it > > properly... > > The code comes from University of Tsukuba. The function is internal to > the module and is safe to use that way if you look at pefs_xts_block_encrypt > and pefs_xts_block_decrypt. That doesn't make it exempt from good coding style or modification to be easier to review... > > It wouldn't be hard to add ciphertext stealing to the opencrypto > > implementation if that is really all that is missing... but.. > > > >> looked at them especially in the case of multiple keys per file system in > >> PEFS. > >> AES-NI interface is not designed to be used outside of opencrypto thus > >> some minor copy-past. > > > > We have discovered that by the "minor" copy/paste we now have an > > inferior implementation of AES-XTS... If it performed similar to the > > one before it, it is over 10x slower than the one that I committed.. > > > >> > I updated the kernel's AES-NI implementation to have a very fast > >> > AES-XTS... Upon looking at your implementation, you have a very > >> > slow implementation as you do not pipeline AES-XTS at all... Please > >> > switch to using the opencrypto version.. You'll then be able to make > >> > use of any accelerators that other platforms may have... > >> > >> I was looking into incorporating AES_XTS pipeline changes in PEFS. > >> I'd like to avoid switching to opencrypto at this point. But pipelining is > >> doable without opencrypto and copying code around. > > > > I really don't like the idea of adding yet anothe AES-XTS implementation > > to our tree (especially considering how bad both the previous one and > > this one is)... Even if you do bring over the pipeline changes... > > It'll be yet another copy of code to maintain and port performance > > improvements too... > > > > We could always refactor the AES-NI code to make it more usable outside > > the opencrypto framework as a stepping stone to possibly using pjd's > > improved opencrypto framework... > > Refactoring AES-NI would be ideal, it would also be great to extract AES-XTS > implementation and make it usable outside of opencrypto adding ciphertext > stealing. As for making it usable outside of opencrypto, I'd prefer that we figure out if we should use pjd's improvements, or if we really want to make AES-NI a first class citizen in the kernel, and if the later, figuring out a proper API for it... I'm nervous that we are rushing these changes into the tree... I do like the idea of getting PEFS into the kernel, but it doesn't feel like it's been properly reviewed/integrated yet... > > But copy/pasting just because we don't want to do a bit more work isn't > > good justification... > > It's not that I "don't want to do a bit more work" I never said that, > it's rather > about avoiding changes after KBI freeze. But will the work get done to clean it up after the freeze is over? What happens if it doesn't, will it get removed before 10.1 or will we have to live w/ the code? > >> > Are there plans to add authentication to this scheme? See that as a > >> > todo, but w/o authentication, you can't store anything reliably on it.. > >> > And w/ XTS, the attacker can take pot shots at your file in 16 byte > >> > chuncks... > >> > >> I have data authentication prototype. It's too far from being complete, > >> and I keep working on it as time permits. There are a few more ideas > >> I'd like to work on while redesigning the file system. > >> > >> Patch also includes hmac and pkcs5v2 implementat
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 5:23 PM, John-Mark Gurney wrote: > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 16:47 -0700: >> On Mon, Oct 7, 2013 at 4:17 PM, John-Mark Gurney wrote: >> > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700: >> >> Patch is available here: >> >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch >> > >> > Is there a reason you are writing your own AES-NI implementation instead >> > of using the OpenCrypto framework? >> >> It reuses the same AES-NI implementation used by opencrypto, >> but code doesn't use opencrypto directly. Main limitation in opencrypto is >> that is incomplete implementation AES-XTS -- it doesn't implement ciphertext >> stealing. opencrypto contexts seemed to be too much overhead list time I > > I remember noticing that when I was working on it.. but as there are > different modes of packing/padding, I decided not to do anything with > that... > > I also don't like your lack of comments arround xts_lastblock and about > why it is accessing dst - 1... To me, you should pass in the previous > block as an arg to xts_lastblock instead of doing dst[-1]... You did > comment what you're doing (m - 1), but not why it is safe to do that... > There is no comment that you're implementing ciphertext stealing w/ the > function which makes it even harder to understand that you'd going it > properly... The code comes from University of Tsukuba. The function is internal to the module and is safe to use that way if you look at pefs_xts_block_encrypt and pefs_xts_block_decrypt. > It wouldn't be hard to add ciphertext stealing to the opencrypto > implementation if that is really all that is missing... but.. > >> looked at them especially in the case of multiple keys per file system in >> PEFS. >> AES-NI interface is not designed to be used outside of opencrypto thus >> some minor copy-past. > > We have discovered that by the "minor" copy/paste we now have an > inferior implementation of AES-XTS... If it performed similar to the > one before it, it is over 10x slower than the one that I committed.. > >> > I updated the kernel's AES-NI implementation to have a very fast >> > AES-XTS... Upon looking at your implementation, you have a very >> > slow implementation as you do not pipeline AES-XTS at all... Please >> > switch to using the opencrypto version.. You'll then be able to make >> > use of any accelerators that other platforms may have... >> >> I was looking into incorporating AES_XTS pipeline changes in PEFS. >> I'd like to avoid switching to opencrypto at this point. But pipelining is >> doable without opencrypto and copying code around. > > I really don't like the idea of adding yet anothe AES-XTS implementation > to our tree (especially considering how bad both the previous one and > this one is)... Even if you do bring over the pipeline changes... > It'll be yet another copy of code to maintain and port performance > improvements too... > > We could always refactor the AES-NI code to make it more usable outside > the opencrypto framework as a stepping stone to possibly using pjd's > improved opencrypto framework... Refactoring AES-NI would be ideal, it would also be great to extract AES-XTS implementation and make it usable outside of opencrypto adding ciphertext stealing. > But copy/pasting just because we don't want to do a bit more work isn't > good justification... It's not that I "don't want to do a bit more work" I never said that, it's rather about avoiding changes after KBI freeze. >> > Are there plans to add authentication to this scheme? See that as a >> > todo, but w/o authentication, you can't store anything reliably on it.. >> > And w/ XTS, the attacker can take pot shots at your file in 16 byte >> > chuncks... >> >> I have data authentication prototype. It's too far from being complete, >> and I keep working on it as time permits. There are a few more ideas >> I'd like to work on while redesigning the file system. >> >> Patch also includes hmac and pkcs5v2 implementations which in fact >> were generic versions to go under sys/crypto until yesterday. >> Considering we are late in code freeze already I've merged them >> into PEFS not to touch geli code with the patch. > > Can't you keep them named the same under sys/crypto and just link w/ them > as necessary to prevent repo churn when you finally integrate them into > sys/crypto? That seems better than moving them arround, though I guess > w/ svn, it isn't as big of a deal... Someone w/ a repo hat on should > chime in here... It won't be possible at least because of pkcs5v2_genkey() (name collision) being defined internally in geli and pkcs5v2 using hmac from geli. Moving them to sys/crypto in 11-CURRENT is a minor issue IMHO. I was pushing those changes to HEAD years ago, but they got stuck somewhere in review process. >> > The only reason I'm running zfs on geli w/o authentication is that I'm >> > using a 256bit checks
Re: Committing PEFS to CURRENT
Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 16:47 -0700: > On Mon, Oct 7, 2013 at 4:17 PM, John-Mark Gurney wrote: > > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700: > >> Patch is available here: > >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch > > > > Is there a reason you are writing your own AES-NI implementation instead > > of using the OpenCrypto framework? > > It reuses the same AES-NI implementation used by opencrypto, > but code doesn't use opencrypto directly. Main limitation in opencrypto is > that is incomplete implementation AES-XTS -- it doesn't implement ciphertext > stealing. opencrypto contexts seemed to be too much overhead list time I I remember noticing that when I was working on it.. but as there are different modes of packing/padding, I decided not to do anything with that... I also don't like your lack of comments arround xts_lastblock and about why it is accessing dst - 1... To me, you should pass in the previous block as an arg to xts_lastblock instead of doing dst[-1]... You did comment what you're doing (m - 1), but not why it is safe to do that... There is no comment that you're implementing ciphertext stealing w/ the function which makes it even harder to understand that you'd going it properly... It wouldn't be hard to add ciphertext stealing to the opencrypto implementation if that is really all that is missing... but.. > looked at them especially in the case of multiple keys per file system in > PEFS. > AES-NI interface is not designed to be used outside of opencrypto thus > some minor copy-past. We have discovered that by the "minor" copy/paste we now have an inferior implementation of AES-XTS... If it performed similar to the one before it, it is over 10x slower than the one that I committed.. > > I updated the kernel's AES-NI implementation to have a very fast > > AES-XTS... Upon looking at your implementation, you have a very > > slow implementation as you do not pipeline AES-XTS at all... Please > > switch to using the opencrypto version.. You'll then be able to make > > use of any accelerators that other platforms may have... > > I was looking into incorporating AES_XTS pipeline changes in PEFS. > I'd like to avoid switching to opencrypto at this point. But pipelining is > doable without opencrypto and copying code around. I really don't like the idea of adding yet anothe AES-XTS implementation to our tree (especially considering how bad both the previous one and this one is)... Even if you do bring over the pipeline changes... It'll be yet another copy of code to maintain and port performance improvements too... We could always refactor the AES-NI code to make it more usable outside the opencrypto framework as a stepping stone to possibly using pjd's improved opencrypto framework... But copy/pasting just because we don't want to do a bit more work isn't good justification... > > Are there plans to add authentication to this scheme? See that as a > > todo, but w/o authentication, you can't store anything reliably on it.. > > And w/ XTS, the attacker can take pot shots at your file in 16 byte > > chuncks... > > I have data authentication prototype. It's too far from being complete, > and I keep working on it as time permits. There are a few more ideas > I'd like to work on while redesigning the file system. > > Patch also includes hmac and pkcs5v2 implementations which in fact > were generic versions to go under sys/crypto until yesterday. > Considering we are late in code freeze already I've merged them > into PEFS not to touch geli code with the patch. Can't you keep them named the same under sys/crypto and just link w/ them as necessary to prevent repo churn when you finally integrate them into sys/crypto? That seems better than moving them arround, though I guess w/ svn, it isn't as big of a deal... Someone w/ a repo hat on should chime in here... > > The only reason I'm running zfs on geli w/o authentication is that I'm > > using a 256bit checksum, so the chances of someone modifing two blocks > > to fool zfs into decrypting the correct new checksum value for their > > modified block is very small... In short, I'm trusting zfs to do the > > authentication for me... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 4:17 PM, John-Mark Gurney wrote: > Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700: >> Patch is available here: >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch > > Is there a reason you are writing your own AES-NI implementation instead > of using the OpenCrypto framework? It reuses the same AES-NI implementation used by opencrypto, but code doesn't use opencrypto directly. Main limitation in opencrypto is that is incomplete implementation AES-XTS -- it doesn't implement ciphertext stealing. opencrypto contexts seemed to be too much overhead list time I looked at them especially in the case of multiple keys per file system in PEFS. AES-NI interface is not designed to be used outside of opencrypto thus some minor copy-past. > I updated the kernel's AES-NI implementation to have a very fast > AES-XTS... Upon looking at your implementation, you have a very > slow implementation as you do not pipeline AES-XTS at all... Please > switch to using the opencrypto version.. You'll then be able to make > use of any accelerators that other platforms may have... I was looking into incorporating AES_XTS pipeline changes in PEFS. I'd like to avoid switching to opencrypto at this point. But pipelining is doable without opencrypto and copying code around. > Are there plans to add authentication to this scheme? See that as a > todo, but w/o authentication, you can't store anything reliably on it.. > And w/ XTS, the attacker can take pot shots at your file in 16 byte > chuncks... I have data authentication prototype. It's too far from being complete, and I keep working on it as time permits. There are a few more ideas I'd like to work on while redesigning the file system. Patch also includes hmac and pkcs5v2 implementations which in fact were generic versions to go under sys/crypto until yesterday. Considering we are late in code freeze already I've merged them into PEFS not to touch geli code with the patch. > The only reason I'm running zfs on geli w/o authentication is that I'm > using a 256bit checksum, so the chances of someone modifing two blocks > to fool zfs into decrypting the correct new checksum value for their > modified block is very small... In short, I'm trusting zfs to do the > authentication for me... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700: > Patch is available here: > https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch Is there a reason you are writing your own AES-NI implementation instead of using the OpenCrypto framework? I updated the kernel's AES-NI implementation to have a very fast AES-XTS... Upon looking at your implementation, you have a very slow implementation as you do not pipeline AES-XTS at all... Please switch to using the opencrypto version.. You'll then be able to make use of any accelerators that other platforms may have... Are there plans to add authentication to this scheme? See that as a todo, but w/o authentication, you can't store anything reliably on it.. And w/ XTS, the attacker can take pot shots at your file in 16 byte chuncks... The only reason I'm running zfs on geli w/o authentication is that I'm using a 256bit checksum, so the chances of someone modifing two blocks to fool zfs into decrypting the correct new checksum value for their modified block is very small... In short, I'm trusting zfs to do the authentication for me... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
Gleb Kurtsou wrote:
> On Mon, Oct 7, 2013 at 12:58 PM, Julian H. Stacey wrote:
> > Hi Gleb & All
> > Gleb Kurtsou wrote:
> >> Hello,
> >>
> >> I would like to ask everybody's opinion regarding committing PEFS to
> >> CURRENT.
> >>
> >> PEFS is a stacked cryptographic file system for FreeBSD. Development
> >> started as Google Summer of Code project in 2009. It has been in ports
> >> since Sept 2011. I maintain the project.
> >>
> >> Conceptually PEFS is similar to nullfs adding encryption layer on top of
> >> it. But it differs technically by not using vop_bypass. Another popular
> >> stacked cryptographic file systems include eCryptfs (linux) and encfs
> >> (fuse). There is also pam_pefs pam module to allow user authentication
> >> with their PEFS-encrypted home directory password.
> >
> > 2 others are also already in FreeBSD src/ (not just ports) gbde & geli.
>
> geli and gbde are different concept, they provide encrypted block level
> devices.
Yes, I allocate eg 2 Gig { via dd on a file on UFS or an MBR partition
on a USB stick }, [then use mdconfig if a file on UFS] before I
gbde, I've always thought I'd have to bite the ZFS bullet to escape
fixed sizing, but PEFS offers variable sizing :-)
> PEFS transparently encrypts data on existing file system.
>
> Here is what you can do with PEFS:
> % mkdir ~/Private
> % pefs mount ~/Private ~/Private
> % pefs addkey ~/Private
> % echo "Hello WORLD" > ~/Private/test
> % ls -Al ~/Private
> total 1
> -rw-r--r-- 1 gleb gleb 12 Oct 1 12:55 test
> % cat ~/Private/test
> Hello WORLD
> % pefs unmount ~/Private
> % ls -Al ~/Private
> total 1
> -rw-r--r-- 1 gleb gleb 12 Oct 1 12:55 .DU6eudxZGtO8Ry_2Z3Sl+tq2hV3O75jq
> % hd ~/Private/.DU6eudxZGtO8Ry_2Z3Sl+tq2hV3O75jq
> 7f 1e 1b 05 fc 8a 5c 38 fc d8 2d 5f |..\8..-_|
> 000c
Nice.
> Take a look a great article in the BSD Magazine or
Downloaded (free)
> http://glebkurtsou.blogspot.com/2009/10/encrypting-private-directory-with-pefs.html
Will do.
> > Whether moved from ports to src or not, either way,
> > I sggest add to man section SEE ALSO gbde(8) & geli(8)
>
> Good point, thanks.
>
>
> > Also, SEE ALSO of gbde & geli should probably ref ports/sysutils/pefs-kmod
> > ft: Command not found.
Sorry, line above my mouse seems to have caught my mistyped vi !}fmt from
elsewhere.
> > No pefs yet i SEE ALSO of
> > http://www.freebsd.org/cgi/man.cgi?query=gbde&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html
> > http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html
> >
> > I suggest add an href inside:
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html
> > Even if just a 1 liner to start, to expand to a section later.
> > (None there for 'pefs', I just searched)
> >
> > Personaly I've been using gbde based on top of a file inside a UFS
> > for a long time, I can't remember why I chose gbde rather than geli,
> > I guess because it was there first ?
> >
> > A dummy's guide short notes along the lines of "Which of these 3 should I
> > use?"
> > might also later be nice at the top of that web page :-)
> >
>
> There is no answer for the question, each system does it's own thing
> and does it differently:
> * With PEFS backups are much easier:
> - Use regular backup software for backing up encrypted data (lower
> level file system), that would allow delta backup only.
Sorry, I don't quite understand what's meant.
( I use rdist6 to backup individual changes in one tree to a tree
on gbde on an mdconfig'd image on a ufs on a remote host or local
USB stick, Easy after set up, all normal tools work, but yes,
target size is fixed unlike PEFS. )
> - Create file system snapshots, e.g. zfs, then zfs send/receive,
> regardless whether file system is encrypted or not.
> * Setting up multiple encrypted file system is much easier -- no need
> to preallocate storage and create file system.
> * With PEFS it's possible to add key to encrypted home directory
> during login (pam_pefs).
> * PEFS let's you use multiple key in same file system.
Useful, I hope it makes it to src/ I suggest contribute summary above to
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html
Thanks
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
Reply below not above, like a play script. Indent old text with "> ".
Send plain text. No quoted-printable, HTML, base64, multipart/alternative.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 12:58 PM, Julian H. Stacey wrote: > Hi Gleb & All > Gleb Kurtsou wrote: >> Hello, >> >> I would like to ask everybody's opinion regarding committing PEFS to >> CURRENT. >> >> PEFS is a stacked cryptographic file system for FreeBSD. Development >> started as Google Summer of Code project in 2009. It has been in ports >> since Sept 2011. I maintain the project. >> >> Conceptually PEFS is similar to nullfs adding encryption layer on top of >> it. But it differs technically by not using vop_bypass. Another popular >> stacked cryptographic file systems include eCryptfs (linux) and encfs >> (fuse). There is also pam_pefs pam module to allow user authentication >> with their PEFS-encrypted home directory password. > > 2 others are also already in FreeBSD src/ (not just ports) gbde & geli. geli and gbde are different concept, they provide encrypted block level devices. PEFS transparently encrypts data on existing file system. Here is what you can do with PEFS: % mkdir ~/Private % pefs mount ~/Private ~/Private % pefs addkey ~/Private % echo "Hello WORLD" > ~/Private/test % ls -Al ~/Private total 1 -rw-r--r-- 1 gleb gleb 12 Oct 1 12:55 test % cat ~/Private/test Hello WORLD % pefs unmount ~/Private % ls -Al ~/Private total 1 -rw-r--r-- 1 gleb gleb 12 Oct 1 12:55 .DU6eudxZGtO8Ry_2Z3Sl+tq2hV3O75jq % hd ~/Private/.DU6eudxZGtO8Ry_2Z3Sl+tq2hV3O75jq 7f 1e 1b 05 fc 8a 5c 38 fc d8 2d 5f |..\8..-_| 000c Take a look a great article in the BSD Magazine or http://glebkurtsou.blogspot.com/2009/10/encrypting-private-directory-with-pefs.html > Whether moved from ports to src or not, either way, > I sggest add to man section SEE ALSO gbde(8) & geli(8) Good point, thanks. > Also, SEE ALSO of gbde & geli should probably ref ports/sysutils/pefs-kmod > ft: Command not found. > > No pefs yet i SEE ALSO of > http://www.freebsd.org/cgi/man.cgi?query=gbde&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html > http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html > > I suggest add an href inside: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html > Even if just a 1 liner to start, to expand to a section later. > (None there for 'pefs', I just searched) > > Personaly I've been using gbde based on top of a file inside a UFS > for a long time, I can't remember why I chose gbde rather than geli, > I guess because it was there first ? > > A dummy's guide short notes along the lines of "Which of these 3 should I > use?" > might also later be nice at the top of that web page :-) > There is no answer for the question, each system does it's own thing and does it differently: * With PEFS backups are much easier: - Use regular backup software for backing up encrypted data (lower level file system), that would allow delta backup only. - Create file system snapshots, e.g. zfs, then zfs send/receive, regardless whether file system is encrypted or not. * Setting up multiple encrypted file system is much easier -- no need to preallocate storage and create file system. * With PEFS it's possible to add key to encrypted home directory during login (pam_pefs). * PEFS let's you use multiple key in same file system. Thanks, Gleb. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On Mon, Oct 7, 2013 at 9:53 AM, Nikolai Lifanov wrote: > On 10/07/13 12:31, Gleb Kurtsou wrote: >> Hello, >> >> I would like to ask everybody's opinion regarding committing PEFS to >> CURRENT. >> >> PEFS is a stacked cryptographic file system for FreeBSD. Development >> started as Google Summer of Code project in 2009. It has been in ports >> since Sept 2011. I maintain the project. >> >> Conceptually PEFS is similar to nullfs adding encryption layer on top of >> it. But it differs technically by not using vop_bypass. Another popular >> stacked cryptographic file systems include eCryptfs (linux) and encfs >> (fuse). There is also pam_pefs pam module to allow user authentication >> with their PEFS-encrypted home directory password. >> >> For those interested in high level introduction I would highly recommend >> article by Kris Moore in the BSD Magazine Issue 09/2013(50) - >> http://bsdmag.org/magazine/1848-day-to-day-bsd-administration >> >> We are very close to branching 10-STABLE now, but patch is >> non-intrusive, it only adds new functionality, enabling PEFS for i386 >> and amd64 (platforms it's known to work on). Patch passes make universe. >> >> Patch is available here: >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch >> >> Pros/cons: >> >> - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS >> who are already committed to use PEFS in next product releases, e.g. >> PCBSD provides encrypted home directories. >> >> - There is steady interest in the project from users (emails, etc). >> Many of them note that file system is not well known yet. Moving PEFS >> to base would greatly increase its exposure. >> >> - Committing PEFS to base would also simplify maintenance by keeping it >> in sync with other subsystems, e.g. it will be updated on large scale >> changes like VM locking. >> >> - There are no bugs known at the moment. I've been using it to encrypt >> home directory since day one. pho@ ran stress test suite on it a >> while back, number of bugs was fixed. >> >> - PEFS is known to work on amd64 and i386 only. Big endian system and >> systems with page size larger than 4k are not tested. >> >> - NOTE! There has been no cryptography review. I'd like to suggest to >> add warning about file system and crypto used is experimental and hasn't >> undergone professional review. Similar to one we had in tmpfs. >> >> >> BSD Magazine article: >> http://bsdmag.org/magazine/1848-day-to-day-bsd-administration >> >> Port: >> http://www.freshports.org/sysutils/pefs-kmod/ >> >> Source code repository: >> https://github.com/glk/pefs >> >> FreeBSD DevSummit'2011 - pefs presentation slides: >> https://pefs.googlecode.com/files/pefs-devsummit.pdf >> >> FreeBSD wiki page: >> https://wiki.freebsd.org/PEFS >> >> >> I would really appreciate any comments or suggestions. >> >> >> Thank you, >> Gleb. > > Just a personal note: I hoped that you would commit pefs to base > someday. It works well, and is the type of a core functionality that > would be nice to have as early as the install ISO, before skel is copied > over for the first user. I would be happy if this happened. > Agree. It would also be nice to have standard way to mount pefs file systems because they need to be mounted at later point during boot after other file systems mounted. Small rc.d script should do the trick. I think those issues should be addressed after PEFS is committed > - Nikolai Lifanov > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
Hi Gleb & All Gleb Kurtsou wrote: > Hello, > > I would like to ask everybody's opinion regarding committing PEFS to > CURRENT. > > PEFS is a stacked cryptographic file system for FreeBSD. Development > started as Google Summer of Code project in 2009. It has been in ports > since Sept 2011. I maintain the project. > > Conceptually PEFS is similar to nullfs adding encryption layer on top of > it. But it differs technically by not using vop_bypass. Another popular > stacked cryptographic file systems include eCryptfs (linux) and encfs > (fuse). There is also pam_pefs pam module to allow user authentication > with their PEFS-encrypted home directory password. 2 others are also already in FreeBSD src/ (not just ports) gbde & geli. Whether moved from ports to src or not, either way, I sggest add to man section SEE ALSO gbde(8) & geli(8) Also, SEE ALSO of gbde & geli should probably ref ports/sysutils/pefs-kmod ft: Command not found. No pefs yet i SEE ALSO of http://www.freebsd.org/cgi/man.cgi?query=gbde&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html I suggest add an href inside: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html Even if just a 1 liner to start, to expand to a section later. (None there for 'pefs', I just searched) Personaly I've been using gbde based on top of a file inside a UFS for a long time, I can't remember why I chose gbde rather than geli, I guess because it was there first ? A dummy's guide short notes along the lines of "Which of these 3 should I use?" might also later be nice at the top of that web page :-) Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Committing PEFS to CURRENT
On 10/07/13 12:31, Gleb Kurtsou wrote: > Hello, > > I would like to ask everybody's opinion regarding committing PEFS to > CURRENT. > > PEFS is a stacked cryptographic file system for FreeBSD. Development > started as Google Summer of Code project in 2009. It has been in ports > since Sept 2011. I maintain the project. > > Conceptually PEFS is similar to nullfs adding encryption layer on top of > it. But it differs technically by not using vop_bypass. Another popular > stacked cryptographic file systems include eCryptfs (linux) and encfs > (fuse). There is also pam_pefs pam module to allow user authentication > with their PEFS-encrypted home directory password. > > For those interested in high level introduction I would highly recommend > article by Kris Moore in the BSD Magazine Issue 09/2013(50) - > http://bsdmag.org/magazine/1848-day-to-day-bsd-administration > > We are very close to branching 10-STABLE now, but patch is > non-intrusive, it only adds new functionality, enabling PEFS for i386 > and amd64 (platforms it's known to work on). Patch passes make universe. > > Patch is available here: > https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch > > Pros/cons: > > - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS > who are already committed to use PEFS in next product releases, e.g. > PCBSD provides encrypted home directories. > > - There is steady interest in the project from users (emails, etc). > Many of them note that file system is not well known yet. Moving PEFS > to base would greatly increase its exposure. > > - Committing PEFS to base would also simplify maintenance by keeping it > in sync with other subsystems, e.g. it will be updated on large scale > changes like VM locking. > > - There are no bugs known at the moment. I've been using it to encrypt > home directory since day one. pho@ ran stress test suite on it a > while back, number of bugs was fixed. > > - PEFS is known to work on amd64 and i386 only. Big endian system and > systems with page size larger than 4k are not tested. > > - NOTE! There has been no cryptography review. I'd like to suggest to > add warning about file system and crypto used is experimental and hasn't > undergone professional review. Similar to one we had in tmpfs. > > > BSD Magazine article: > http://bsdmag.org/magazine/1848-day-to-day-bsd-administration > > Port: > http://www.freshports.org/sysutils/pefs-kmod/ > > Source code repository: > https://github.com/glk/pefs > > FreeBSD DevSummit'2011 - pefs presentation slides: > https://pefs.googlecode.com/files/pefs-devsummit.pdf > > FreeBSD wiki page: > https://wiki.freebsd.org/PEFS > > > I would really appreciate any comments or suggestions. > > > Thank you, > Gleb. Just a personal note: I hoped that you would commit pefs to base someday. It works well, and is the type of a core functionality that would be nice to have as early as the install ISO, before skel is copied over for the first user. I would be happy if this happened. - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Committing PEFS to CURRENT
Hello, I would like to ask everybody's opinion regarding committing PEFS to CURRENT. PEFS is a stacked cryptographic file system for FreeBSD. Development started as Google Summer of Code project in 2009. It has been in ports since Sept 2011. I maintain the project. Conceptually PEFS is similar to nullfs adding encryption layer on top of it. But it differs technically by not using vop_bypass. Another popular stacked cryptographic file systems include eCryptfs (linux) and encfs (fuse). There is also pam_pefs pam module to allow user authentication with their PEFS-encrypted home directory password. For those interested in high level introduction I would highly recommend article by Kris Moore in the BSD Magazine Issue 09/2013(50) - http://bsdmag.org/magazine/1848-day-to-day-bsd-administration We are very close to branching 10-STABLE now, but patch is non-intrusive, it only adds new functionality, enabling PEFS for i386 and amd64 (platforms it's known to work on). Patch passes make universe. Patch is available here: https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch Pros/cons: - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS who are already committed to use PEFS in next product releases, e.g. PCBSD provides encrypted home directories. - There is steady interest in the project from users (emails, etc). Many of them note that file system is not well known yet. Moving PEFS to base would greatly increase its exposure. - Committing PEFS to base would also simplify maintenance by keeping it in sync with other subsystems, e.g. it will be updated on large scale changes like VM locking. - There are no bugs known at the moment. I've been using it to encrypt home directory since day one. pho@ ran stress test suite on it a while back, number of bugs was fixed. - PEFS is known to work on amd64 and i386 only. Big endian system and systems with page size larger than 4k are not tested. - NOTE! There has been no cryptography review. I'd like to suggest to add warning about file system and crypto used is experimental and hasn't undergone professional review. Similar to one we had in tmpfs. BSD Magazine article: http://bsdmag.org/magazine/1848-day-to-day-bsd-administration Port: http://www.freshports.org/sysutils/pefs-kmod/ Source code repository: https://github.com/glk/pefs FreeBSD DevSummit'2011 - pefs presentation slides: https://pefs.googlecode.com/files/pefs-devsummit.pdf FreeBSD wiki page: https://wiki.freebsd.org/PEFS I would really appreciate any comments or suggestions. Thank you, Gleb. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
