 |
|
Kaak
|
|
Okay, I have a very serious problem. Back in march, I went into file properties, then advanced, and encrypted some files. Since, I have reinstalled my OD (same OS, xp, just formatted a drive and did a clean install). now, i cannot open the files. it says access is denied. Is there anything i can do to fix this???
thanks in advance
|
|
| |
|
|
|
Dr. A. Cula
|
|
If you encripted the file, you probably supplied a password during this process. Without it, you can't access the file.
If you remembered to write down the password, did you remember to install the encription package?
|
|
| |
|
|
|
Kaak
|
|
so, is it possible to get one of these recovery keys?
|
|
| |
|
| |
|
|
|
Sir Ralph
|
 |
Long live teh Schwampel!
Dec 2001
time: 06:30
|
|
quote:
Originally posted by Asher
People encrypt their files because it's both important and sensitive, and the existance of a "recovery key" ensures both, provided you keep the recovery key safe (ie, on a floppy/usb drive that you keep with you).
Nothing's worse than reinstalling the OS and finding out all your sensitive, important information can no longer be accessed, even by you. Hence the (optional) recovery keys. |
Given the recovery key is your personal property and no one else would be able to generate one, you are right. In this case the word "recovery" is redundant, though, it's just the key you're storing, may be with a bit of "bla bla" around it. With the same key you can decode your encrypted data after you reinstalled the OS. To call it "Recovery certificate" is just misleading and leads to the question, who except me can hold such a certificate for my data.
What I'm talking about are backdoors to the encryption system. For instance are there easy methods to make "master keys" in key encryption algorithm, which greatly reduce the width of the used key.
An example: For the sake of simplicity, let's assume we encrypt our data with a 6-digit decimal number. That's at least, what the key generator gives us. What we don't know is, that the generator spits out only multiples of, say, 1357. That's not obvious, if you look at the 6 digit key. We think, a brute force attacker has to go through 1,000,000 possibilities for the key, but in fact it are only 1,000,000 / 1,357 = ~737. Compare 1 million and 737, quite a difference, no?
The reality is of course not that simple, but there are similar methods to store such "master keys" like the number 1357 in my example at the police, the CIA, NSA, Mossad or whatever, which reduce a keywidth of 128 bit to 40 bit or similar. I think I encrypted it with 128 bit and so it is for everyone except those with the "master key". For them it's only a weak 40 bit encryption. You get the message.
As long as an encryption algorithm is not thoroughly described and open in it's algorithmus and software, I would refuse to use it. Answer me a simple question: Are you sure there's no backdoor (as described) in the Windows encryption system?
|
|
| |
|
|
|
Asher
|
 |
Calgary, Alberta
Nov 1999
time: 22:30
|
|
quote:
Originally posted by Urban Ranger
I am also curious as to what cyher protocol is used in Windows XP. It's not one of the public ones, is it? |
From the MS Whitepaper:
quote:
EFS implements data encryption and decryption using a public key-based scheme. File data is encrypted using a fast symmetric algorithm with a file encryption key (FEK). The FEK is a randomly generated key of a certain length required by the algorithm or by law if the algorithm supports variable length keys. Export issues relating to EFS are discussed below in this document.
The FEK is encrypted using one or more key encryption public keys to generate a list of encrypted FEKs. The public portion of a user's key pair is used to encrypt FEKs. This public portion of the user’s key pair is obtained from the User’s X509 version 3 certificate, with enhanced key usage as “File Encryption”. The list of encrypted FEKs is stored along with this encrypted file in a special EFS attribute called the Data Decryption Field (DDF). The file encryption information is tightly bound to the file. The private portion of the user’s key pair is used during decryption. The FEK is decrypted using the private portion of the key pair. The private portion of a user’s key pair is stored safely elsewhere in smart cards or other secure storage such as the integrated software-based protected store used by CryptoAPI.
The FEK is also encrypted using one or more recovery key encryption public keys (obtained from the recovery agent X509 version 3 certificates stored in the Encrypted Data Recovery Agent (EDRA) Policy for the computer—the enhanced key usage for these certificates must be “File Recovery”). Again, the public portion of each key pair is used to encrypt FEKs. This list of encrypted FEKs is also stored along with the file in a special EFS attribute called the Data Recovery Field (DRF). Only public portions of the recovery key pairs are needed for encryption of the FEK in the DRF. These public recovery keys are required to be present at all times on an EFS system for normal file system operations. They are present in EDRA policy as X509 version 3 “File Recovery” certificates. Recovery itself is expected to be a rare operation required only when users leave organizations or lose keys. Because of this, recovery agents can store the private portions of the keys safely elsewhere (on smart cards and other secure storage devices).
Security Considerations
Encrypting File System is a strong security technology for physical protection of stored data. To that end, it is necessary to look at its various features and do a security analysis. In this section we look at various threats and how EFS handles them:
• Attempt to open other users’ encrypted files—EFS is designed to be transparent under the normal mode of operation. When a user attempts to open a file encrypted by another user, EFS attempts to locate the private key which will decrypt the FEK during the open. Since the calling user will not possess the key, FEK will not get decrypted and hence the attempt will failed with “Access Denied”.
• Attempt to bypass recovery policy—EFS does not allow any new encryption of files/folders if there is no recovery policy. If the machine is joined to a domain, the EFS policy is propagated from the domain as part of Group Policy and enforced by EFS on the machine. A local administrator’s attempt to define a local EFS policy also does not work because policy from the domain takes precedence. The only option for a local administrator on the machine would be to remove the machine from the domain—doing so will no longer allow users to logon to the machine using domain credentials
• Attempt to destroy recovery policy—A local administrator may attempt to locate the EFS policy storage and attempt to delete or replace it. Deletion will not help because that will disable EFS. Replacing EFS with another recovery policy will not work because it will soon be overwritten by policy from domain.
• Physically access to the media—An individual with physical access to the machine could potentially attempt sophisticated attacks by going to the disk directly. Attempts to read the data this way will fail because it is encrypted and a successful process would require implementing EFS itself. Another possible attack with physical access can be to invalidate or delete the recovery portion on the encrypted file. This will not still not work because EFS will automatically recreate the recovery information when the file is successfully opened next time.
• Recovery from fatal failures during encryption/decryption operations—EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. OTE: Creating a plaintext copy hasthe side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file. For this reason, it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc.
• Handling recovery policy changes—As discussed above, a user with physical access to the machine may attempt to scramble the recovery information on the file. It is also possible that recovery policy is changed by administrators at the domain because of various reasons such as the expiration of certificates, change of recovery agent, and so forth. When a particular encrypted file is opened, EFS will check whether the recovery information on the file is current. If not, it is recomputed. This is because recovery information for the file can not be updated without a decrypted FEK which becomes available only when the file is opened. Encrypted files that are not touched for long periods of time may have stale recovery policy, it is therefore very important that recovery certificates and private keys be maintained for several years even after the recovery policy has changed.
• Handling user certificate or key changes—Just like the recovery policy changes, user certificate or key changes are handled when a particular file is opened. EFS determines if the key used to open the file is current. If not, the data decryption field is updated on the file using the user’s current key. Note, that recovery agents should also continue to hold on to there old keys unless they are sure that all encrypted files have started using the new key. However, users can be more relaxed than because users can depend on recovery agents to decrypt their data in case they lose or destroy keys.
• Protecting the system from becoming unbootable—Another important piece to understand is that EFS is intended to encrypt or decrypt user data. System data such as the registry, system DLLs and other files needed during system boot up must never be encrypted because EFS doesn’t become active until the operating system is running. Therefore, if any of the files used by the operating system are encrypted, the system will be rendered useless. EFS provides some level of protection by disallowing encryption of files or folders with system attribute designations. |
As far as I know, the actual cyphers used are private for enhanced security.
|
|
| |
|
|
|
Kaak
|
|
why exactly are you guys arguing about this?
|
|
| |
|
|
|
Kaak
|
|
talking about what a tragedy it was to lose naked pictures of her^^^
|
|
| |
All times are GMT. The time now is 05:30.
Apolyton Time is 00:30. |
top of page
|
| archivepost |
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
21-08-2003 15:03
It has to be YOUR recovery key
Attachment: 
|
