List Info

Thread: Problem with ntfsdecrypt and PKCS#1 padding




Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-17 08:34:41
% ntfsdecrypt --version

ntfsdecrypt v1.13.1 (libntfs 9:0:0) - Decrypt files and
print on the
standard output.

% ntfsdecrypt -k /home/...pfx /dev/sda1
"dir/file"
Enter the password with which the private key was encrypted:
**********
Failed to remove PKCS#1 padding from decrypted file
encryption key.
Failed to decrypt the file encryption key.
Failed to obtain file encryption key.  Aborting.

What can I do now?

Matt

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

Re: Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-17 08:44:59
Hi,

On 17 Sep 2007, at 14:34, Matthew A. Postiff wrote:
> % ntfsdecrypt --version
>
> ntfsdecrypt v1.13.1 (libntfs 9:0:0) - Decrypt files and
print on the
> standard output.
>
> % ntfsdecrypt -k /home/...pfx /dev/sda1
"dir/file"
> Enter the password with which the private key was
encrypted:  
> **********
> Failed to remove PKCS#1 padding from decrypted file
encryption key.
> Failed to decrypt the file encryption key.
> Failed to obtain file encryption key.  Aborting.
>
> What can I do now?

Please try the latest version (in CVS) or even better wait a
few days  
for us to release ntfsprogs 2.0.0 and then try with them.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at
with )
Unix Support, Computing Service, University of Cambridge,
CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/




------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

Re: Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-17 09:20:36
Hi Anton,

I rebuilt from a fresh cvs checkout just now:

% ntfsdecrypt --version

ntfsdecrypt v2.0.0 (libntfs 10:0:0) - Decrypt files and
print on the
standard output.

% ./ntfsdecrypt -k /home/...pfx /dev/sda1
"dir/file"
Enter the password with which the private key was encrypted:
*********
There are no entries in the DRF array.
Failed to obtain file encryption key.  Aborting.

I was sort of afraid this might be the outcome, but I'm not
sure what to
do at this point. The files on /dev/sda1 were copied from
Windows XP as
encrypted backup files. Later my original drive has crashed,
but I had
saved off the PFX file and had my password stored safely
away. So I
don't have access to the original profile on that machine
with its SID
or whatever. Is it the case I might not have backed up
certain key files
(i.e. the one containing the FEK)? If so, am I hosed or is
there still hope?

Matt

Anton Altaparmakov wrote:
> Hi,
>
> On 17 Sep 2007, at 14:34, Matthew A. Postiff wrote:
>> % ntfsdecrypt --version
>>
>> ntfsdecrypt v1.13.1 (libntfs 9:0:0) - Decrypt files
and print on the
>> standard output.
>>
>> % ntfsdecrypt -k /home/...pfx /dev/sda1
"dir/file"
>> Enter the password with which the private key was
encrypted: **********
>> Failed to remove PKCS#1 padding from decrypted file
encryption key.
>> Failed to decrypt the file encryption key.
>> Failed to obtain file encryption key.  Aborting.
>>
>> What can I do now?
>
> Please try the latest version (in CVS) or even better
wait a few days
> for us to release ntfsprogs 2.0.0 and then try with
them.
>
> Best regards,
>
>     Anton

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

Re: Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-17 09:39:56
Hi Matthew,

On 17 Sep 2007, at 15:20, Matthew A. Postiff wrote:
> I rebuilt from a fresh cvs checkout just now:
>
> % ntfsdecrypt --version
>
> ntfsdecrypt v2.0.0 (libntfs 10:0:0) - Decrypt files and
print on the
> standard output.
>
> % ./ntfsdecrypt -k /home/...pfx /dev/sda1
"dir/file"
> Enter the password with which the private key was
encrypted: *********
> There are no entries in the DRF array.
> Failed to obtain file encryption key.  Aborting.
>
> I was sort of afraid this might be the outcome, but I'm
not sure  
> what to do at this point. The files on /dev/sda1 were
copied from  
> Windows XP as encrypted backup files.

Sorry I do not understand what you mean.  Could you explain
what this  
copying involved?

> Later my original drive has crashed, but I had saved
off the PFX  
> file and had my password stored safely away. So I don't
have access  
> to the original profile on that machine with its SID or
whatever.  
> Is it the case I might not have backed up certain key
files (i.e.  
> the one containing the FEK)? If so, am I hosed or is
there still hope?

The FEK is inside the MFT record of the encrypted file...

Two things to try:

1) Apply attached patch to you CVS checkout of
ntfsdecrypt.c,  
recompile and try again.



2) Run: ntfsinfo /dev/sda1 -vvvF "dir/file"
And send the output it generates.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at
with )
Unix Support, Computing Service, University of Cambridge,
CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/




------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

  
Re: Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-17 10:10:57
Hi Anton,

Thanks for the quick replies. /dev/sda1 is an external USB
hard drive.
The copying involved simply dragging/dropping various
unencrypted
directories/files from my WinXP documents dir to the
external USB drive.
Then I right-clicked those directories on the USB drive and
told XP to
encrypt them. Since my XP system crashed, I unhooked the USB
drive from
it and attached it as /dev/sda1 to my Linux system.

I now understand what you are saying about the FEK being in
the MFT,
though I don't know the significance of that fact in my
particular case.

I applied your patch, rebuilt, and re-ran ntfsdecrypt, with
exactly the
same result as in my previous email.

ntfsinfo /dev/sda1 -vvvF "dir/file"  >
ntfsinfo.output.txt
    is attached.

Matt

Anton Altaparmakov wrote:
> Hi Matthew,
>
> On 17 Sep 2007, at 15:20, Matthew A. Postiff wrote:
>> I rebuilt from a fresh cvs checkout just now:
>>
>> % ntfsdecrypt --version
>>
>> ntfsdecrypt v2.0.0 (libntfs 10:0:0) - Decrypt files
and print on the
>> standard output.
>>
>> % ./ntfsdecrypt -k /home/...pfx /dev/sda1
"dir/file"
>> Enter the password with which the private key was
encrypted: *********
>> There are no entries in the DRF array.
>> Failed to obtain file encryption key.  Aborting.
>>
>> I was sort of afraid this might be the outcome, but
I'm not sure what
>> to do at this point. The files on /dev/sda1 were
copied from Windows
>> XP as encrypted backup files.
>
> Sorry I do not understand what you mean.  Could you
explain what this
> copying involved?
>
>> Later my original drive has crashed, but I had
saved off the PFX file
>> and had my password stored safely away. So I don't
have access to the
>> original profile on that machine with its SID or
whatever. Is it the
>> case I might not have backed up certain key files
(i.e. the one
>> containing the FEK)? If so, am I hosed or is there
still hope?
>
> The FEK is inside the MFT record of the encrypted
file...
>
> Two things to try:
>
> 1) Apply attached patch to you CVS checkout of
ntfsdecrypt.c,
> recompile and try again.
>
>
> 2) Run: ntfsinfo /dev/sda1 -vvvF "dir/file"
> And send the output it generates.
>
> Best regards,
>
>     Anton

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

  
Re: Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-19 03:00:47
Hi Matthew,

On 17 Sep 2007, at 16:10, Matthew A. Postiff wrote:
> Thanks for the quick replies. /dev/sda1 is an external
USB hard  
> drive.  The copying involved simply dragging/dropping
various  
> unencrypted directories/files from my WinXP documents
dir to the  
> external USB drive. Then I right-clicked those
directories on the  
> USB drive and told XP to encrypt them.

Great!  I was worried when you said backup that you used
some backup  
application that went and did something weird...

> Since my XP system crashed, I unhooked the USB drive
from it and  
> attached it as /dev/sda1 to my Linux system.
>
> I now understand what you are saying about the FEK
being in the  
> MFT, though I don't know the significance of that fact
in my  
> particular case.

The FEK is the key that allows you to decrypt the file. 
Without it  
it is impossible to do the decryption (unless you were to
brute force  
it and happened to have more computing power than all
computers on  
the planet put together at your disposal!).

The FEK is stored in the $LOGGED_UTILITY_STREAM:$EFS
attribute in the  
MFT record of each encrypted file.

Things are not quite so simple as the FEK is encrypted with
another  
key (this is an RSA key).  Thus you need the RSA private key
to be  
able to decrypt the FEK and thus to be able to decrypt the
file.

The RSA private key is what is stored in the .pfx file when
you  
export your private key in Windows hence why we need the
.pfx file.   
We parse it then decrypt the .pfx file using the password
you give to  
ntfsdecrypt then this gives us the RSA key which we use to
decrypt  
the FEK in the $EFS attribute and then we use the decrypted
FEK to  
decrypt the file data.

> I applied your patch, rebuilt, and re-ran ntfsdecrypt,
with exactly  
> the same result as in my previous email.

Sorry my patch did not quite do what I intended!  Could you
revert  
that patch and apply the attached one instead and try again?
 Thanks!



> ntfsinfo /dev/sda1 -vvvF "dir/file"  >
ntfsinfo.output.txt
>     is attached.
[snip]
> Dumping attribute $LOGGED_UTILITY_STREAM (0x100)
> 	Attribute length:	 80 (0x50)
> 	Resident: 		 No
> 	Name length:		 4 (0x4)
> 	Name offset:		 64 (0x40)
> 	Attribute name:		 '$EFS'
> 	Attribute flags:	 0x0000
> 	Attribute instance:	 6 (0x6)
> 	Lowest VCN		 0 (0x0)
> 	Highest VCN:		 0 (0x0)
> 	Mapping pairs offset:	 72 (0x48)
> 	Compression unit:	 0 (0x0)
> 	Data size:		 552 (0x228)
> 	Allocated size:		 4096 (0x1000)
> 	Initialized size:	 552 (0x228)
> 	Runlist:	VCN		LCN		Length
> 			0x0		0x17a5e86		0x1

Ok, that shows the files are indeed regular encrypted files.
 So far  
so good.  We should be able to decrypt them fine as long as
we can  
deal with your .pfx file.

Can I please ask where this .pfx file came from?  How did
you create  
it?  When did you create it?  In particular did you export
it in  
Windows using the cipher.exe command or via the GUI?  And if
via the  
GUI what options did you click?  And finally very important
did you  
do the export on the same Windows installation as you did
the  
encryption on?  Did you change your password in between
exporting  
the .pfx file and doing the encryption?

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at
with )
Unix Support, Computing Service, University of Cambridge,
CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/




------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

  
Re: Problem with ntfsdecrypt and PKCS#1 padding
user name
2007-09-19 03:37:20
And could you either search and replace all occurrences of 

"ntfs_log_debug" with "ntfs_log_info" in
ntfsdecrypt.c or apply the  
attached patch on top of the previous one?  This is so we
see a bit  
more what is going on...

Thanks,

	Anton



On 19 Sep 2007, at 09:00, Anton Altaparmakov wrote:

> Hi Matthew,
>
> On 17 Sep 2007, at 16:10, Matthew A. Postiff wrote:
>> Thanks for the quick replies. /dev/sda1 is an
external USB hard  
>> drive.  The copying involved simply
dragging/dropping various  
>> unencrypted directories/files from my WinXP
documents dir to the  
>> external USB drive. Then I right-clicked those
directories on the  
>> USB drive and told XP to encrypt them.
>
> Great!  I was worried when you said backup that you
used some  
> backup application that went and did something
weird...
>
>> Since my XP system crashed, I unhooked the USB
drive from it and  
>> attached it as /dev/sda1 to my Linux system.
>>
>> I now understand what you are saying about the FEK
being in the  
>> MFT, though I don't know the significance of that
fact in my  
>> particular case.
>
> The FEK is the key that allows you to decrypt the file.
 Without it  
> it is impossible to do the decryption (unless you were
to brute  
> force it and happened to have more computing power than
all  
> computers on the planet put together at your
disposal!).
>
> The FEK is stored in the $LOGGED_UTILITY_STREAM:$EFS
attribute in  
> the MFT record of each encrypted file.
>
> Things are not quite so simple as the FEK is encrypted
with another  
> key (this is an RSA key).  Thus you need the RSA
private key to be  
> able to decrypt the FEK and thus to be able to decrypt
the file.
>
> The RSA private key is what is stored in the .pfx file
when you  
> export your private key in Windows hence why we need
the .pfx  
> file.  We parse it then decrypt the .pfx file using the
password  
> you give to ntfsdecrypt then this gives us the RSA key
which we use  
> to decrypt the FEK in the $EFS attribute and then we
use the  
> decrypted FEK to decrypt the file data.
>
>> I applied your patch, rebuilt, and re-ran
ntfsdecrypt, with  
>> exactly the same result as in my previous email.
>
> Sorry my patch did not quite do what I intended!  Could
you revert  
> that patch and apply the attached one instead and try
again?  Thanks!
>
> <ntfsdecrypt.c-2.diff>
>
>> ntfsinfo /dev/sda1 -vvvF "dir/file"  >
ntfsinfo.output.txt
>>     is attached.
> [snip]
>> Dumping attribute $LOGGED_UTILITY_STREAM (0x100)
>> 	Attribute length:	 80 (0x50)
>> 	Resident: 		 No
>> 	Name length:		 4 (0x4)
>> 	Name offset:		 64 (0x40)
>> 	Attribute name:		 '$EFS'
>> 	Attribute flags:	 0x0000
>> 	Attribute instance:	 6 (0x6)
>> 	Lowest VCN		 0 (0x0)
>> 	Highest VCN:		 0 (0x0)
>> 	Mapping pairs offset:	 72 (0x48)
>> 	Compression unit:	 0 (0x0)
>> 	Data size:		 552 (0x228)
>> 	Allocated size:		 4096 (0x1000)
>> 	Initialized size:	 552 (0x228)
>> 	Runlist:	VCN		LCN		Length
>> 			0x0		0x17a5e86		0x1
>
> Ok, that shows the files are indeed regular encrypted
files.  So  
> far so good.  We should be able to decrypt them fine as
long as we  
> can deal with your .pfx file.
>
> Can I please ask where this .pfx file came from?  How
did you  
> create it?  When did you create it?  In particular did
you export  
> it in Windows using the cipher.exe command or via the
GUI?  And if  
> via the GUI what options did you click?  And finally
very important  
> did you do the export on the same Windows installation
as you did  
> the encryption on?  Did you change your password in
between  
> exporting the .pfx file and doing the encryption?
>
> Best regards,
>
> 	Anton

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at
with )
Unix Support, Computing Service, University of Cambridge,
CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/




------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-Userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user

  
[1-7]

about | contact  Other archives ( Real Estate discussion Medical topics )