Re: DPAPI implemented in Crypt32.dll

From: Alan Croston (anonymous_at_discussions.microsoft.com)
Date: 02/27/04

  • Next message: Rob Elder, MVP-Networking: "Re: Only Windows 2000 DCs w/ WNT WKS?"
    Date: Fri, 27 Feb 2004 01:43:10 -0800
    
    

    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.
    >
    >
    >"Alan Croston" <anonymous@discussions.microsoft.com>
    wrote in message
    >news:270c01c3fc7e$d0c2ebe0$a301280a@phx.gbl...
    >> 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
    >>
    >>
    >>
    >>
    >
    >
    >.
    >


  • Next message: Rob Elder, MVP-Networking: "Re: Only Windows 2000 DCs w/ WNT WKS?"

    Relevant Pages

    • Re: Could a hacker achieve this?
      ... Stealing the DLL is one task and probably the hardest. ... Now if we assume that the hacker has gained entry to your machine and can ... it was encrypted on, with DPAPI ... So you could either use DPAPI for all your encryption needs or just to ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: Could a hacker achieve this?
      ... > assume a standard .Net app with the DLL in the bin folder, ... > Now if we assume that the hacker has gained entry to your machine and can ... > it was encrypted on, with DPAPI ... > store/encrypt the encryption key that you will be using. ...
      (microsoft.public.dotnet.framework.aspnet.security)
    • Re: DPAPI implemented in Crypt32.dll
      ... DPAPI problem, I'll let the DPAPI dev and tester know that you're having a ... > activex dll and I could debug easier. ... >>> I have implemented a file encryption solution using ...
      (microsoft.public.win2000.security)
    • Re: DPAPI implemented in Crypt32.dll
      ... A workaround is to use something that calls CryptEncrypt instead. ... If you want encryption that ultimately relies on DPAPI (more or less what ... >> activex dll and I could debug easier. ...
      (microsoft.public.win2000.security)
    • Re: Java Applet Funktionalität in ASP.Net
      ... Ja indem du per Tag eine dotnet dll einbindest, ... Programmierung, also Applets, ActiveX, einschließlich javascript. ... ..NET Framework basierende Komponente" ist also keineswegs unsicherer. ... Packe dein Windows Formular in eine Windows Control Library, ...
      (microsoft.public.de.german.entwickler.dotnet.asp)