DPAPI implemented in Crypt32.dll

[Alan Croston]

Greetings all,

This is fun (I had hair when I discovered this yesterday,
none today!)

I have implemented a file encryption solution using
windows XP. this uses DPAPI and calls it via a COM object
I obtained. I then make calls to this COM object like
Encrypt(blob, filepath) and Decrypt(filepath, filename).

This works great on windows xp. I have tested encryption
on files up to 120 MB. I can also decrypt these files
(Very useful lol!)

However, i moved the code onto windows 2000 server and
the call to the Crypt32.dll fails with "Automation Error:
Remote Procedure Call Failed". It only does this when I
try to encrypt files over about 300 kbytes. Anything less
than 300 kbytes works great! Why does it fail when it
works fine on xp?

I have checked the versions of the dlls and XP has a
later (larger in size) version of the Crypt32.dll, so
obviously there were changes between 2000 and XP possibly
impacting the implementation of the DP API.

2000 version 5.131.2195.6661 (Supplied with 2000 SP4)
XP version 5.131.2600.1106 (Supplied with XP SP1)

I have checked my code and produced versions that allow
me to debug right up to the point where the DPAPI method
Encrypt / Decrypt is called from my Visual Basic 6 code.
The method is called... there is a pause... and the when
I get the err.getLastDLLError I get the RPC failed
message. So I am 99.999% sure that the version of Crypt32
is to blame.

Can anyone tell me what is happening? Is there any way
that I can get around this problem e.g. coping the
Crypt32.dll over from XP to 2000? Will that work? Can I
upgrade the 2000 Crypt32 dll?

The really frustrating thing is that there is hardly any
info on DPAPI on the internet at all and even less of
Crypt32.dll problems. Surely I cannot be the only person
on the planet using DPAPI to encrypt / decrypt files!!!
(Knowing my current luck I am! lol)

Anyway, something for you guys to ponder over if you get
the chance. I would appreciate anyones info that may help
me to resolve this!

Thanks in anticipation

Regards

Alan Croston

 

[Drew Cooper [MSFT]]

"via a COM object I obtained"
Aha! I had to re-read that post a couple of times until I saw that.

The DPAPI API for encrypting data is CryptProtectData. For decrypting, it's
CryptUnprotectData. The COM object must be calling those if it's using
DPAPI.

If you call a COM object and fail with an RPC error, wouldn't you suspect
that the COM object has a bug? COM implies RPC . . .


Also: You probably don't want to copy binaries from an XP install to a Win2k
one. While an app might work ok, it's really unlikely that a system dll
will work on a downlevel platform.

 

[Alan Croston]

I just re-read that and yes, it's amusing. I downloaded
it off a code site as a VB class and compiled it as an
active x dll. This all works fine on XP, but not on 2000.
I even combined the class into my VB app so there was no
activex dll and I could debug easier. DPAPI fails when I
call CryptProtectData or CryptUnprotectData passing in
Blobs (binary large objects) greater than 300k in size
into those functions and so the problem canNOT be at the
ActiveX dll level. I am very certain it is because DPAPI
is breaking and not my code.

Can you enlighten me as to what might be going on?

Thanks and Regards

Alan Croston

-----Original Message-----
"via a COM object I obtained"
Aha! I had to re-read that post a couple of times until I saw that.

The DPAPI API for encrypting data is CryptProtectData. For decrypting, it's
CryptUnprotectData. The COM object must be calling those if it's using
DPAPI.

If you call a COM object and fail with an RPC error, wouldn't you suspect
that the COM object has a bug? COM implies RPC . . .


Also: You probably don't want to copy binaries from an XP install to a Win2k
one. While an app might work ok, it's really unlikely that a system dll
will work on a downlevel platform.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Greetings all,

This is fun (I had hair when I discovered this yesterday,
none today!)

I have implemented a file encryption solution using
windows XP. this uses DPAPI and calls it via a COM object
I obtained. I then make calls to this COM object like
Encrypt(blob, filepath) and Decrypt(filepath, filename).

This works great on windows xp. I have tested encryption
on files up to 120 MB. I can also decrypt these files
(Very useful lol!)

However, i moved the code onto windows 2000 server and
the call to the Crypt32.dll fails with "Automation Error:
Remote Procedure Call Failed". It only does this when I
try to encrypt files over about 300 kbytes. Anything less
than 300 kbytes works great! Why does it fail when it
works fine on xp?

I have checked the versions of the dlls and XP has a
later (larger in size) version of the Crypt32.dll, so
obviously there were changes between 2000 and XP possibly
impacting the implementation of the DP API.

2000 version 5.131.2195.6661 (Supplied with 2000 SP4)
XP version 5.131.2600.1106 (Supplied with XP SP1)

I have checked my code and produced versions that allow
me to debug right up to the point where the DPAPI method
Encrypt / Decrypt is called from my Visual Basic 6 code.
The method is called... there is a pause... and the when
I get the err.getLastDLLError I get the RPC failed
message. So I am 99.999% sure that the version of Crypt32
is to blame.

Can anyone tell me what is happening? Is there any way
that I can get around this problem e.g. coping the
Crypt32.dll over from XP to 2000? Will that work? Can I
upgrade the 2000 Crypt32 dll?

The really frustrating thing is that there is hardly any
info on DPAPI on the internet at all and even less of
Crypt32.dll problems. Surely I cannot be the only person
on the planet using DPAPI to encrypt / decrypt files!!!
(Knowing my current luck I am! lol)

Anyway, something for you guys to ponder over if you get
the chance. I would appreciate anyones info that may help
me to resolve this!

Thanks in anticipation

Regards

Alan Croston

.

 

[Drew Cooper [MSFT]]

I can't offer enlightenment personally, but now that it seems more like a
DPAPI problem, I'll let the DPAPI dev and tester know that you're having a
problem. One of them can probably help.

(Also: I know that the dev hangs out on
microsoft.public.platformsdk.security - if you re-post there, you'll
probably get his attention.)
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

I just re-read that and yes, it's amusing. I downloaded
it off a code site as a VB class and compiled it as an
active x dll. This all works fine on XP, but not on 2000.
I even combined the class into my VB app so there was no
activex dll and I could debug easier. DPAPI fails when I
call CryptProtectData or CryptUnprotectData passing in
Blobs (binary large objects) greater than 300k in size
into those functions and so the problem canNOT be at the
ActiveX dll level. I am very certain it is because DPAPI
is breaking and not my code.

Can you enlighten me as to what might be going on?

Thanks and Regards

Alan Croston

-----Original Message-----
"via a COM object I obtained"
Aha! I had to re-read that post a couple of times until I saw that.

The DPAPI API for encrypting data is CryptProtectData. For decrypting, it's
CryptUnprotectData. The COM object must be calling those if it's using
DPAPI.

If you call a COM object and fail with an RPC error, wouldn't you suspect
that the COM object has a bug? COM implies RPC . . .


Also: You probably don't want to copy binaries from an XP install to a Win2k
one. While an app might work ok, it's really unlikely that a system dll
will work on a downlevel platform.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

Greetings all,

This is fun (I had hair when I discovered this yesterday,
none today!)

I have implemented a file encryption solution using
windows XP. this uses DPAPI and calls it via a COM object
I obtained. I then make calls to this COM object like
Encrypt(blob, filepath) and Decrypt(filepath, filename).

This works great on windows xp. I have tested encryption
on files up to 120 MB. I can also decrypt these files
(Very useful lol!)

However, i moved the code onto windows 2000 server and
the call to the Crypt32.dll fails with "Automation Error:
Remote Procedure Call Failed". It only does this when I
try to encrypt files over about 300 kbytes. Anything less
than 300 kbytes works great! Why does it fail when it
works fine on xp?

I have checked the versions of the dlls and XP has a
later (larger in size) version of the Crypt32.dll, so
obviously there were changes between 2000 and XP possibly
impacting the implementation of the DP API.

2000 version 5.131.2195.6661 (Supplied with 2000 SP4)
XP version 5.131.2600.1106 (Supplied with XP SP1)

I have checked my code and produced versions that allow
me to debug right up to the point where the DPAPI method
Encrypt / Decrypt is called from my Visual Basic 6 code.
The method is called... there is a pause... and the when
I get the err.getLastDLLError I get the RPC failed
message. So I am 99.999% sure that the version of Crypt32
is to blame.

Can anyone tell me what is happening? Is there any way
that I can get around this problem e.g. coping the
Crypt32.dll over from XP to 2000? Will that work? Can I
upgrade the 2000 Crypt32 dll?

The really frustrating thing is that there is hardly any
info on DPAPI on the internet at all and even less of
Crypt32.dll problems. Surely I cannot be the only person
on the planet using DPAPI to encrypt / decrypt files!!!
(Knowing my current luck I am! lol)

Anyway, something for you guys to ponder over if you get
the chance. I would appreciate anyones info that may help
me to resolve this!

Thanks in anticipation

Regards

Alan Croston

.

 

[Drew Cooper [MSFT]]

Evidently this is a known bug in Win2k. :-(

A workaround is to use something that calls CryptEncrypt instead. Unlike
DPAPI (even without the bug), with CryptEncrypt you can encrypt data of
arbitrary length. And you can choose your algorithm, CSP, etc. If you have
any questions about CryptEncrypt, you'll get your best responses on
microsoft.public.platformsdk.security.

If you want encryption that ultimately relies on DPAPI (more or less what
your COM object solution does), we do offer EFS on Win2k and later releases
of Windows.

Sorry - that's all the help I can be.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

I can't offer enlightenment personally, but now that it seems more like a
DPAPI problem, I'll let the DPAPI dev and tester know that you're having a
problem. One of them can probably help.

(Also: I know that the dev hangs out on
microsoft.public.platformsdk.security - if you re-post there, you'll
probably get his attention.)
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.

I just re-read that and yes, it's amusing. I downloaded
it off a code site as a VB class and compiled it as an
active x dll. This all works fine on XP, but not on 2000.
I even combined the class into my VB app so there was no
activex dll and I could debug easier. DPAPI fails when I
call CryptProtectData or CryptUnprotectData passing in
Blobs (binary large objects) greater than 300k in size
into those functions and so the problem canNOT be at the
ActiveX dll level. I am very certain it is because DPAPI
is breaking and not my code.

Can you enlighten me as to what might be going on?

Thanks and Regards

Alan Croston

-----Original Message-----
"via a COM object I obtained"
Aha! I had to re-read that post a couple of times until I saw that.

The DPAPI API for encrypting data is CryptProtectData. For decrypting, it's
CryptUnprotectData. The COM object must be calling those if it's using
DPAPI.

If you call a COM object and fail with an RPC error, wouldn't you suspect
that the COM object has a bug? COM implies RPC . . .


Also: You probably don't want to copy binaries from an XP install to a Win2k
one. While an app might work ok, it's really unlikely that a system dll
will work on a downlevel platform.
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.


Greetings all,

This is fun (I had hair when I discovered this yesterday,
none today!)

I have implemented a file encryption solution using
windows XP. this uses DPAPI and calls it via a COM object
I obtained. I then make calls to this COM object like
Encrypt(blob, filepath) and Decrypt(filepath, filename).

This works great on windows xp. I have tested encryption
on files up to 120 MB. I can also decrypt these files
(Very useful lol!)

However, i moved the code onto windows 2000 server and
the call to the Crypt32.dll fails with "Automation Error:
Remote Procedure Call Failed". It only does this when I
try to encrypt files over about 300 kbytes. Anything less
than 300 kbytes works great! Why does it fail when it
works fine on xp?

I have checked the versions of the dlls and XP has a
later (larger in size) version of the Crypt32.dll, so
obviously there were changes between 2000 and XP possibly
impacting the implementation of the DP API.

2000 version 5.131.2195.6661 (Supplied with 2000 SP4)
XP version 5.131.2600.1106 (Supplied with XP SP1)

I have checked my code and produced versions that allow
me to debug right up to the point where the DPAPI method
Encrypt / Decrypt is called from my Visual Basic 6 code.
The method is called... there is a pause... and the when
I get the err.getLastDLLError I get the RPC failed
message. So I am 99.999% sure that the version of Crypt32
is to blame.

Can anyone tell me what is happening? Is there any way
that I can get around this problem e.g. coping the
Crypt32.dll over from XP to 2000? Will that work? Can I
upgrade the 2000 Crypt32 dll?

The really frustrating thing is that there is hardly any
info on DPAPI on the internet at all and even less of
Crypt32.dll problems. Surely I cannot be the only person
on the planet using DPAPI to encrypt / decrypt files!!!
(Knowing my current luck I am! lol)

Anyway, something for you guys to ponder over if you get
the chance. I would appreciate anyones info that may help
me to resolve this!

Thanks in anticipation

Regards

Alan Croston






.