Talk:Encrypting File System
|This article is of interest to the following WikiProjects:|
File system on file system?
Is EFS, so to speak, a file system on another file system (NTFS)? --Abdull 18:49, 28 November 2005 (UTC)
- Yep, it seems so. From the first external link: "EFS protects sensitive data in files that are stored on disk using the NTFS file system". — Matt Crypto 18:57, 28 November 2005 (UTC)
- No. EFS is not a file system. It is an add-on to NTFS where the data gets encrypted and some information needed to decrypt the data is stored in a NTFS stream.
— Dominik Weber 6/13/2006
- No. EFS is currently described by Microsoft as a component driver, and was previously compared to filesystem filters (which is a reasonable approximation of the net effect). It merely intercepts calls to some APIs such as CreateFile() and performs the decryption needed to service the API request.
This article conflicts with it self. The majority of the article says that the files are encrypted with a symetric encryption algorithim with that key that is in turn encrypted asymetrically.
However, the Recovery part of the Security section says that the files are not even encrypted. There are some space/comma problems. Looks like a defacement to me? —Preceding unsigned comment added by 184.108.40.206 (talk)
if "encrypting file system" is a windows only thing a disambiguation link at the top would help. I know similar things exist for Mac and Linux. --220.127.116.11 21:50, 22 September 2006 (UTC)
- Filesystems with embedded cryptographic features do exist on other OSs (e.g. CryptoFS on Linux) but the existing documentation appears to point out that they are separate (and incompatible) implementations of the same basic idea (i.e. cryptographic support is done "just in time" when writing/reading bits to/from the physical device). So it appears that "Encrypting File System" (and "EFS" as an acronym in this sense) is indeed a Windows-only thing. I will update the article accordingly. --Mauro Cicognini (talk) 13:30, 11 January 2010 (UTC
hello man this is
AES or 3DES
I've added a table called "Algorithms Used by Operating System Version". Does that provide the clarity you're asking for?--ParanoidMike 14:12, 14 August 2007 (UTC)
REG_DWORD value named AlgorithmID.
0x6604: Use the DESX algorithm, which is compatible with all versions of Windows 2000 and Windows XP.
0x6603: Use the 3DES algorithm, which is compatible with all versions of Windows XP and Windows Server 2003.
0x6610: Use the AES 256-bit algorithm (the default value, which is only compatible with Windows XP SP1 or later, Windows Server 2003 and Windows Vista).
Seen on: http://searchwinit.techtarget.com/tip/0,289483,sid1_gci935154,00.html?topic=299543 —Preceding unsigned comment added by 18.104.22.168 (talk)
- Further to this, even if the same encryption algorithm is used by Windows XP (or Windows Server 2003) and Windows Vista, EFS encrypted files accessed, created or modified by Windowd Vista are rendered inaccessible in Windows XP (and Windows Server 2003) despite the files being previously accessible.
- http://support.microsoft.com/kb/939391 --22.214.171.124 04:37, 8 August 2007 (UTC)
Why does CryptFS redirect to this page? The *Nix FS and the Win FS is different. 126.96.36.199 16:04, 10 March 2007 (UTC)
Common misunderstandings about EFS ?
Are the statements listed there "misunderstandigs" i.e. false, or are they true ? --Xerces8 19:20, 21 September 2007 (UTC)
- Some of them are definitely false (at least in XP, do not have enough knowledge about 2k). Don't know about the rest. Also they are uncited. So, I think, they should probably be removed for now pending citing and verification. --soum talk 07:58, 22 September 2007 (UTC)
Versions with EFS
There is an error while saying that Windows Premium includes EFS.
As seen here: http://www.microsoft.com/latam/windows/products/windowsvista/editions/choose.mspx Windows Home Preimum does not support it —Preceding unsigned comment added by 188.8.131.52 (talk) 15:32, 16 January 2008 (UTC)
Visible file and directory names ?
My experience shows, that even when a volume is encrypted from the root (that is all maps and files), all the file and directory names are visible. They are not encrypted. Usually when "hiding" files, one also don't want the file and folder structure to be visible to others. Is there something to be done ? Some setting that also encrypts the file and directory names ? --Xerces8 (talk) 10:58, 18 April 2008 (UTC)
- EFS is not used for "hiding" files and folders. Rather it is used to make file data unusable. You can couple it with file/folder permissions to make that folder out of bounds to unauthorized users. --soum talk 12:40, 18 April 2008 (UTC)
- Using MS EFS and file/folder permissions doesn't give that much protection. Instead you should use some real disk encryption software like TrueCrypt that encrypts the whole disk volume or even better the whole disk. Then nothing is visible for attackers who don't have the password/key, they can't even see if the disk has any files or not.
- --David Göthberg (talk) 13:10, 18 April 2008 (UTC)
- EFS is not designed to protect privacy; rather it's designed to protect security by making file contents unusable for someone who can't decrypt them. A quick-and-dirty way to hide file names and directory structure, whether using EFS or not, is to compress the files into an encrypted 7z archive with the 7-Zip utility (selecting LZMA2 compression and AES encryption, and also enabling the file name encryption checkbox). Sofia Koutsouveli (talk) 18:00, 12 March 2014 (UTC)
EFS and Bitlocker
- Yeah, me to. If I remember it and have time, I'll do it (if it's not already there). The simple explanation is that Bitlocker encrypts an entire partition, for whatever it's worth over network, while EFS is an NTFS addition that provides some automatic single-file encryption for most entities saved in an encryption marked directory, for whatever it's worth over network. In my mind, a reliable encryption system does this in a similar way as EFS, but does never decrypt a file before sending it over a network, instead the file is sent encrypted over the network and decrypted locally in a user-invisible cache, which is automagically overwritten by the system when the user saves and closes the file. Rursus dixit. (mbork3!) 16:40, 30 September 2011 (UTC)
- That's right we should surely mention Bitlocker in the article. EFS is a feature provided by the NTFS file system and should work independently of the operating system as long as the O/S supports this NTFS feature, whereas Bitlocker is a program included in some versions of the Microsoft Windows operating system and doesn't involve the NTFS EFS feature. So, the EFS feature is more low-level and thus more direct than the Bitlocker feature. In theory, if you had another O/S which could work with NTFS then it could also work with EFS encryption whereas it wouldn't work with Bitlocker encryption, unless it also had its own program implementing Bitlocker's capabilities. Sofia Koutsouveli (talk) 17:46, 12 March 2014 (UTC)
The security section is a bit vague to me. It says there are "two significant security vulnerabilities in Windows 2000" but doesn't explicitly state what those are. Also if anyone could add if these are still an issue in later versions, i think it would be quite helpful. TizzyFoe (talk) 18:23, 24 September 2008 (UTC)
EFS vs Compression
Is there any reason, except the usual Win-mismodularity, that makes it impossible to compress an EFS-encrypted file? Manually compressing a file by say gzip, and then encrypting it should provide no problem whatsoever, but why is it impossible in the Win7 file properties dialog? Rursus dixit. (mbork3!) 16:33, 30 September 2011 (UTC)
- It's a Windows problem rather than a general encryption-and-compression problem. Microsoft could have implemented this right if they really wanted. Sofia Koutsouveli (talk) 17:49, 12 March 2014 (UTC)
The article has a heavy bias in favor of Microsoft. It mentions in detail all different shades and brands of encrypting file systems in Windows and neglects other operating systems, which have more advanced encrypting file systems. On the other hand it fails to mention all threats posed by the Microsoft solution (such as backdoors and the impossibility to do an independent code and security review since the source code is not published) — Preceding unsigned comment added by 184.108.40.206 (talk) 12:16, 20 November 2013 (UTC)
- You've evidently confused this article on an NTFS feature with a survey article on filesystem-level encryption. The "heavy bias" is in fact topicality. Yappy2bhere (talk) 23:58, 30 November 2013 (UTC)