Windows XP help!!!!!!!!!!!!!!!!!!!

Kaak · August 21, 2003, 06:03

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 · August 21, 2003, 07:23

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?

red_jon · August 21, 2003, 08:13

Take off your shirt. Take pictures.

It could help.

Kirnwaffen · August 21, 2003, 08:45

You're screwed. Windows ties it's encryption keys to your user password, but even if you had that, you still wouldn't have the entire key. What you need is a recovery certificate, and I'm guessing you don't have one.

Harovan · August 21, 2003, 09:11

Quote:

What you need is a recovery certificate

The existence of such a certificate alone renders that whole "encryption" stuff in Windows utterly useless. It's a fake like so many other things.

Asher · August 21, 2003, 09:14

Quote:

Originally posted by Sir Ralph
The existence of such a certificate alone renders that whole "encryption" stuff in Windows utterly useless. It's a fake like so many other things.

Do you understand how key cryptography works?

Harovan · August 21, 2003, 09:22

Quote:

Originally posted by Asher
Do you understand how key cryptography works?

Yes, and I bet better than you.

The existance of "Master keys" or "Recovery keys" alone represent backdoors to the key encryption and renders them useless.

Asher · August 21, 2003, 10:19

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.

Kaak · August 21, 2003, 10:23

so, is it possible to get one of these recovery keys?

reds4ever · August 21, 2003, 10:25

Quote:

Originally posted by Kaak
so, is it possible to get one of these recovery keys?

It has to be YOUR recovery key

Asher · August 21, 2003, 10:34

As far as I know, you had to make the key yourself beforehand if you wanted one.

Harovan · August 21, 2003, 10:40

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?

Urban Ranger · August 21, 2003, 23:48

I am also curious as to what cyher protocol is used in Windows XP. It's not one of the public ones, is it?

Asher · August 21, 2003, 23:52

Quote:

Originally posted by Sir Ralph
Answer me a simple question: Are you sure there's no backdoor (as described) in the Windows encryption system?

The only "back door" is the user-generated recovery key.

The US government (and 7 other nations, now) have looked at the code extensively to ensure there's no backdoors. The US government even gave Windows 2000, XP Pro, and 2003 higher C2 security classification than Linux in part due to the very-well implemented encrypting file system.

The most secure way you could do it, is IBM's Security Subsystem 2.0 like I've got on my new ThinkPad. It's got a TCPA-compliant chip on it, and your keys and encryption is dealt with on its own pool of protected RAM and processor to prevent snooping.

Kaak · August 22, 2003, 00:26

wow....then i have lost a lot of very nice naked pictures of my ex

Kirnwaffen · August 22, 2003, 01:01

Quote:

wow....then i have lost a lot of very nice naked pictures of my ex

Well, there's always the next ex...

Asher · August 22, 2003, 01:08

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.

reds4ever · August 22, 2003, 01:16

Quote:

Originally posted by Kaak
wow....then i have lost a lot of very nice naked pictures of my ex

the 'naughty' looking one you posted pics of a while ago?

Kaak · August 22, 2003, 01:22

nope, still have those...this was the next ex

Urban Ranger · August 22, 2003, 02:05

Quote:

Originally posted by Asher
As far as I know, the actual cyphers used are private for enhanced security.

That's what I am worried about. A robust modern encryption protocol (or algorithm) should hide nothing in itself, the secret should be just in the keys. It's much easier to replace lost keys than programs with leaked algorithm(s).

Anyway, there are two weaknesses I can see right off the bat here. The encryption system is based on PGP/GPG. but the "fast symmetric algorithm" is proprietary (PGP uses 128-bit IDEA), which could be easily broken depending on key length and actual algorithm. Another thing is the DRF (data recovery field) seems easily replaced, thus an attacker can replace the original key with his own, bypassing the system entirely.

Harovan · August 22, 2003, 02:23

Asher, this "description" you posted talks a lot and says nothing. What algorithm do they use? What's the bit width of the keys? I mean, can you prove me wrong, if I state the thesis, that this encryption is a simple xor over an 8 bit value? And btw, security certificates by the US government, the Mafia and the world association of philatelists mean equally nothing to me.

Kaak · August 22, 2003, 20:13

why exactly are you guys arguing about this?

Kuciwalker · August 22, 2003, 20:15

What else is OT for?

Kaak · August 22, 2003, 20:28

talking about what a tragedy it was to lose naked pictures of her^^^

Kirnwaffen · August 22, 2003, 20:49

Quote:

why exactly are you guys arguing about this?

This is the OT. Any tech related question will be immediately answered with a debate over which of the related pieces of software/hardware is better/more reliable/more compatible/prettier...etc. Some people seem to take arguments against certain pieces of software personally...

reds4ever · August 22, 2003, 21:09

Quote:

Originally posted by Kaak
nope, still have those...this was the next ex

Top ****ger!

blackice · August 22, 2003, 23:16

This too is one of the main reason's, say German military dumped MS. Sir Ralph has got it right Asher read on, MS tagged this as a flaw some time back. Several simple programs can get his info back.

Quote:

Another thing is the DRF (data recovery field) seems easily replaced, thus an attacker can replace the original key with his own, bypassing the system entirely.

Which too was posted to MS about july 8th of this year and yes your're right. They posted a shhhhhhhhh! in response to this one too...

blackice · August 23, 2003, 00:18

It would depend if you had sp1 installed at the time or not.

Oerdin · August 23, 2003, 00:25

When I reinstalled XP they saved my old installation as a different log in. If you still have your old log in then you can access it that way. Failing that use system restore to restore your system to the point before the reinstallation and unencrypt the files.