EFS symmetric algorithm

  • Thread starter Thread starter Levy
  • Start date Start date
L

Levy

Hello,

Does anybody know what symmetric algorithm is used by EFS to encrypt files on NTFS volumes? I have to manually decrypt such a file and so far I am successful in recovering and decrypting a FEK (file encryption key, stored in a LOGGED_UTILITY_STREAM attribute of the MFT entry).

Supposedly, the decrypted FEK should be a cryptographic key that I should be able to use with a symmetric encryption engine. The actual data is like this (in hex):

20 00 00 00 00 01 00 00 10 66 00 00
00 00 00 00 13 ab 11 82 52 d7 46 e2
d1 3d 60 40 e7 3a 9f e2 6f 9f 61 86
2d a1 1e d5 e8

I expected to be able to create a CAPI context using CryptAcquireContext() and then import this key with CryptImportKey() but it does not work. It seems to be a structure, and I suspect that in it the type and flag and key size of the symmetric algorithm are specified. The first WORD or DWORD is the size of the actual key material (highlighted in blue).

Does anybody know how to get a HCRYPTKEY from this data, so that I can decrypt the actual content of the file?

Thanks,
Levente
 
Levy said:
Does anybody know what symmetric algorithm is used by EFS to encrypt
files on NTFS volumes?
Click to expand...

That depends on your Windows version an Servicepack level.
W2K uses DESX, WinXP (without SP) is also capable of using 3DES and if you
have installed XP SP1 AES_256 is also available.

Which symmetric cipher is used can be determined by the following registry
key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS

For detailed information see
http://support.microsoft.com/default.aspx?scid=kb;en-us;329741&sd=tech

Fup set to microsoft.public.security.crypto

Jan
 
I accidentaly cut off some bytes from the buffer in my initial post. Its
size is actually 48 bytes. But I do not understand how to get a HCRYPTKEY
from this info.

My understanding is that CryptImportKey (in reverse of what CryptExportKey
does) decrypts a chunk of data with a given key (this is usually a user
private key) and then from the result it builds a HCRYPTKEY. This also
matches my scenario, where the FEK (key for AES 256-bits) is encrypted with
a user's public key.

Well, my problem is that I get a key for the user private key (to get the
decrypted FEK) by using CryptAcquireCertificatePrivateKey and I do not get
asked what provider to use. Thus, the HCRYPTKEY for the user private key is
using a provider that does not support AES (the symmetric algorithm used to
encrypt the file's content, and for which the FEK is actually the key). And
then CryptImportKey requires both HCRYPTKEYs to come from the same provider.
I'm locked out at this point.

I am thinking about manually implementing AES! Help, I am desperate!

Regards,
Levente
 
CryptImportKey does not necessarily DECRYPT the imported key - it depends on
the blob type. If it's PUBLICKEYBLOB or PLAINTEXTKEYBLOB than no decryption
is done, the key value just imported as it is present in the key blob.
(Warning: make sure your PUBLICKEYBLOB is in LSB byte order, which is usually
the reverse of how public keys are stored in other systems and in
certificates.)

Laszlo Elteto
SafeNet, Inc.
 
Back
Top