Re: Stupid Symantec
On 3/16/2018 9:16 AM, Steven Maddox wrote: > I get the impression they want the decryption happening on the end users > machines. > > Presumably so that if any users got the idea to just 'upload' a file > online - it'd be the encrypted version of that file. Course someone can > just get around that by opening an encrypted file - then just saving it > to a new local location :D Since it is automatically decrypted when opened, the uploaded file would be decrypted. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On 3/16/2018 9:15 AM, Andrew Gallagher wrote: > How does that work when the decryption key is on the client? I don't think it is on the client. The private key is stored on the server and is decrypted when you log in. At least I think that's how it works. I've never actually tried using EFS on a server. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
I get the impression they want the decryption happening on the end users machines. Presumably so that if any users got the idea to just 'upload' a file online - it'd be the encrypted version of that file. Course someone can just get around that by opening an encrypted file - then just saving it to a new local location :D But I don't make the rules around here. Steven Maddox Lantizia On 16/03/18 13:07, Phil Susi wrote: > On 3/16/2018 4:11 AM, Steven Maddox wrote: >> Yeah I just use LUKS on my PC to protect local files, but this is (as >> above) for files on SMB/Windows shares... sorry for not mentioning that >> sooner. > I believe you can enable EFS on the windows server and it will handle > decrypting the file before sending it over SMB. Then you don't need any > special software or configuration on the clients. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
> On 16 Mar 2018, at 13:07, Phil Susi wrote: > > I believe you can enable EFS on the windows server and it will handle > decrypting the file before sending it over SMB. Then you don't need any > special software or configuration on the clients. How does that work when the decryption key is on the client? A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On 3/16/2018 4:11 AM, Steven Maddox wrote: > Yeah I just use LUKS on my PC to protect local files, but this is (as > above) for files on SMB/Windows shares... sorry for not mentioning that > sooner. I believe you can enable EFS on the windows server and it will handle decrypting the file before sending it over SMB. Then you don't need any special software or configuration on the clients. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
> On 16 Mar 2018, at 08:11, Steven Maddox wrote: > > Yeah this would be a cool approach that'd mean less reliance on the > kernel. However the files we (me and my colleagues) access (although > they're all using Windows PCs) are on SMB/Windows shares... so somehow > the overlay would have to work with that. If you mounted the remote filesystem using smbfs you should be able to mount an overlayfs over the top, just like any other mounted filesystem. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On 15/03/18 17:03, Phil Susi wrote: > Windows has this feature built in already, why not just use that? I'm not a Windows user, I mentioned that I'm a Linux desktop user in my original post. -- On 15/03/18 17:11, Andrew Gallagher wrote: > The obvious approach would be to write a FUSE driver Yeah this would be a cool approach that'd mean less reliance on the kernel. However the files we (me and my colleagues) access (although they're all using Windows PCs) are on SMB/Windows shares... so somehow the overlay would have to work with that. -- On 15/03/18 17:11, Andrew Gallagher wrote: > I saw a commercial product here that might do what you want I'll take a closer look thanks... although on first glance I can't see anything about SMB/Windows share support (for remote files it just mentions SSH). -- On 15/03/18 22:39, Daniel Kahn Gillmor wrote: > you could look into ext4's native encryption features and... On 16/03/18 00:58, gn...@raf.org wrote: > luks full disk encryption would be best Yeah I just use LUKS on my PC to protect local files, but this is (as above) for files on SMB/Windows shares... sorry for not mentioning that sooner. -- Any other ideas welcome :) To be honest I was kind of hoping someone would pop up an say there was a PGP-compatible open source alternative kernel module that did the same thing! Perhaps this was something the PGP guys kept closed source and Symantec have continued to keep it that way since they bought them out? -- Steven Maddox Lantizia ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On 03/15/2018 07:58 PM, gn...@raf.org wrote: > yes, luks full disk encryption would be best of course but if > boss says no, ecryptfs file system encryption might be > acceptable. every file in an ecryptfs-mounted file system is > individually encrypted. encrypting their names as well is > optional. and it's easy enough to setup. and i haven't detected > any performance penalty (except when running du, just don't). > and i'm fairly sure ubuntu has this built-in for home directory > encryption but i don't know which versions. It goes back to at least 14.04, probably much farther. I haven't done many fresh installs of the older versions. I did two fresh installs of 12.04, with everything since being upgrades (I only use LTS versions now). -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On Fri 2018-03-16 11:58:45 +1100, gn...@raf.org wrote: > Daniel Kahn Gillmor wrote: >> or, if what you really care about is file-level encryption on a >> GNU/Linux desktop and you *don't* care about files being OpenPGP >> formatted, you could look into ext4's native encryption features (see >> e4crypt(8) and related docs to get started). > > yes, luks full disk encryption would be best of course but if > boss says no, ecryptfs file system encryption might be > acceptable. every file in an ecryptfs-mounted file system is > individually encrypted. encrypting their names as well is > optional. and it's easy enough to setup. and i haven't detected > any performance penalty (except when running du, just don't). > and i'm fairly sure ubuntu has this built-in for home directory > encryption but i don't know which versions. note that for fike-level encryption, i was not talking about ecryptfs, but rather about e4crypt. these are different technologies, and i would suspect (though i haven't profiled it) that e4crypt would be significantly more performant than ecryptfs. fwiw, i think that block-device level encryption (e.g. dmcrypt with LUKS) is orthogonal to file-level encryption (e.g. e4crypt). they have different use cases against different adversaries, and there's no clear argument that i've seen that you shouldn't use them in concert with one another. for example, consider the "fast secure delete" functionality that you get from file-level encryption -- delete the inode of a file (which contains the file's key) and then the on-disk data for the file will be unrecoverable. this isn't achievable with block-device-level crypto -- as long as the block device is unlocked, the old blocks are still readable. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
Daniel Kahn Gillmor wrote: > On Thu 2018-03-15 17:11:15 +, Andrew Gallagher wrote: > >> If this doesn't exist in the main GnuPG project then I'd be happy to be > >> referred to any 3rd party bits of software (even if commercial or > >> proprietary) that could? > >> > >> I understand if the answer *should* be block-level encryption... but > >> they're intend on file-level. > > > > The obvious approach would be to write a FUSE driver. It would be > > mounted as an overlay filesystem, and this filesystem would decrypt the > > encrypted files on demand into a ramfs, and then re-encrypt (and shred) > > on file close. > > or, if what you really care about is file-level encryption on a > GNU/Linux desktop and you *don't* care about files being OpenPGP > formatted, you could look into ext4's native encryption features (see > e4crypt(8) and related docs to get started). > > --dkg yes, luks full disk encryption would be best of course but if boss says no, ecryptfs file system encryption might be acceptable. every file in an ecryptfs-mounted file system is individually encrypted. encrypting their names as well is optional. and it's easy enough to setup. and i haven't detected any performance penalty (except when running du, just don't). and i'm fairly sure ubuntu has this built-in for home directory encryption but i don't know which versions. cheers, raf ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On Thu 2018-03-15 17:11:15 +, Andrew Gallagher wrote: >> If this doesn't exist in the main GnuPG project then I'd be happy to be >> referred to any 3rd party bits of software (even if commercial or >> proprietary) that could? >> >> I understand if the answer *should* be block-level encryption... but >> they're intend on file-level. > > The obvious approach would be to write a FUSE driver. It would be > mounted as an overlay filesystem, and this filesystem would decrypt the > encrypted files on demand into a ramfs, and then re-encrypt (and shred) > on file close. or, if what you really care about is file-level encryption on a GNU/Linux desktop and you *don't* care about files being OpenPGP formatted, you could look into ext4's native encryption features (see e4crypt(8) and related docs to get started). --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On 15/03/18 15:26, Steven Maddox wrote: > > The desktop portion of that software has an OS/kernel level driver that > watches if you're trying to open a PGP encrypted file... then decrypts > it on the fly and finally passes it to the application that'd normally > open it. ... > If this doesn't exist in the main GnuPG project then I'd be happy to be > referred to any 3rd party bits of software (even if commercial or > proprietary) that could? > > I understand if the answer *should* be block-level encryption... but > they're intend on file-level. The obvious approach would be to write a FUSE driver. It would be mounted as an overlay filesystem, and this filesystem would decrypt the encrypted files on demand into a ramfs, and then re-encrypt (and shred) on file close. I saw a commercial product here that might do what you want, but the documentation is making my brain hurt: https://www.flam.de/issues/view.php?id=888 http://www.flam.de/en/technology/products/fluc/ -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Stupid Symantec
On 3/15/2018 11:26 AM, Steven Maddox wrote: > The desktop portion of that software has an OS/kernel level driver that > watches if you're trying to open a PGP encrypted file... then decrypts > it on the fly and finally passes it to the application that'd normally > open it. > Anyway I can either continue to bitterly rant or convince my employers > to switch product. Does GnuPG have a similar kernel module/driver for > an as-you-open-a-file type experience? Windows has this feature built in already, why not just use that? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Stupid Symantec
Hi, At the place I work they unfortunately use stupid Symantec's "Encryption Desktop" (formerly known as PGP Desktop) software. The desktop portion of that software has an OS/kernel level driver that watches if you're trying to open a PGP encrypted file... then decrypts it on the fly and finally passes it to the application that'd normally open it. I'm the only Linux desktop user here at work and I only call Symantec *stupid* because they seem to find it funny to support Ubuntu 14.04 all the way to 14.04.4 ... but not 14.04.5. Basically 14.04.5 has a newer Linux kernel which breaks the driver, if they could just fix that - they'd also find it is magically fixed for Ubuntu 16.04 too (as it's the same issue in the kernel that uses too). This is especially infuriating as they refer to any request to fix this as a "Feature Request"... which is laughable if you consider the idea of this happening if Windows got a new service pack, that'd get classified instantly as a bug to fix. See... https://support.symantec.com/en_US/article.TECH236718.html See... https://support.symantec.com/en_US/article.INFO3856.html Anyway I can either continue to bitterly rant or convince my employers to switch product. Does GnuPG have a similar kernel module/driver for an as-you-open-a-file type experience? If this doesn't exist in the main GnuPG project then I'd be happy to be referred to any 3rd party bits of software (even if commercial or proprietary) that could? I understand if the answer *should* be block-level encryption... but they're intend on file-level. -- Steven Maddox Lantizia ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
