DPAPI or not DPAPI, that is the question
From: Andrew Edward (spam_at_spam.spam)
Date: 10/29/03
- Next message: Panga Tc: "Re: CAPI - crypt and decrypt using public/private key pairs"
- Previous message: Sergio Dutra [MS]: "Re: CryptoAPI: forcing CRL checking"
- Next in thread: Andrew Edward: "Re: DPAPI or not DPAPI, that is the question"
- Reply: Andrew Edward: "Re: DPAPI or not DPAPI, that is the question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Oct 2003 13:27:49 -0500
Windows platforms: stand-alone Windows 2000 and stand-alone Windows XP (I
can't assume it's the pro version)
Application overview: Our application is a system service. It generates
data throughout the day which it needs to encrypt and write to disk for
end-of day processing. We must retain the encrypted data on disk for
archival purposes because we sometimes need to go back weeks or months to
reprocess old data. It will sometimes be necessary (for hardware and
operating system maintenance reasons) to copy the encrypted data to a
different computer and be able to decrypt it there in order to process it.
I've been trying to search MSDN, the Knowledge Base, Google Groups, and the
web in general for the answer to the following question: If we use DPAPI
(on stand-alone Windows 2000 and stand-alone Windows XP), is there a
fool-proof procedure a human can follow to export all the "magic stuff"
DPAPI uses to decrypt data and import it into another computer so that the
other computer can also decrypt the data the original computer encrypted?
My gut feeling from the searching I've been doing is that this is NOT
feasible and that we should therefore not use DPAPI. It looks like if we
could prereq profiles maintained on Windows servers DPAPI might work just
fine (but unfortunately we can't prereq a server environment so that option
is not available to us). Am I wrong? Can our application use DPAPI
successfully?
If we can't use DPAPI, I guess we just have to maintain our own key so our
application can load it each time the system boots (so it can encrypt and
decrypt data) and so that the key can be transferred to and used on another
PC. What it boils down to is our key needs to be easier to export and
import than DPAPI's key(s). We need to err on the side of making sure the
users don't lose access to their data whereas DPAPI seems to err (from what
I've been able to glean from my searching...this may NOT be true!) on the
side of making sure the data remains secure (even if it means losing it).
Again, that's assuming what I've gleaned from my searching is correct.
Maybe exporting and importing the DPAPI key(s) is easy and we'll be able to
use it in our application. I hope that's the case.
Thanks in advance!
Andrew
- Next message: Panga Tc: "Re: CAPI - crypt and decrypt using public/private key pairs"
- Previous message: Sergio Dutra [MS]: "Re: CryptoAPI: forcing CRL checking"
- Next in thread: Andrew Edward: "Re: DPAPI or not DPAPI, that is the question"
- Reply: Andrew Edward: "Re: DPAPI or not DPAPI, that is the question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]