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

[Kirnwaffen]

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

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

[Asher]

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:

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]

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]

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

[Urban Ranger]

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]

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]

why exactly are you guys arguing about this?

[Kuciwalker]

What else is OT for?

[Kaak]

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

[Kirnwaffen]

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]

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

Top ****ger!

[blackice]

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.

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]

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

[Dinner]

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.