|
List Info
Thread: Problem with ntfsdecrypt and PKCS#1 padding
|
|
| Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
| Re: Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
| Re: Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
| Re: Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
|
| Re: Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
|
| Re: Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
|
| Re: Problem with ntfsdecrypt and PKCS#1
padding |

|
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/
a>
_______________________________________________
Linux-NTFS-User mailing list
Linux-NTFS-User lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-n
tfs-user
|
|
|
[1-7]
|
|