Hi Kees,
If I understand correctly, you want me to:
- parse the Windows data format as best I can
- produce output that looks like the Windows data format
- do some kind of encryption on the data so that nothing needs to be stored to the computer between calls of CryptProtectData and CryptUnprotectData. (The existing patches intentionally avoid any encryption.)
From looking at Wine's configure.ac, it seems safe to depend on openssl being available. Is that correct?
Someone previously posted pretty good information about the format of CryptProtectData on MSDN. I think it should be possible to implement a close facsimile, except that the user's credentials (password) would be missing in Wine since there isn't any at the moment. If you have time to do this, it would be ideal. Failing that, doing any stateless transformation (e.g. no change at all, or xor-ing with some magic value) would be preferrable to storing this data in the registry, if I understood Alexandre's comments correctly.
We're trying to avoid proliferation of OpenSSL in Wine. Relying on CryptoAPI is a safer bet.
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, May 03, 2005 at 01:58:18PM -0700, Juan Lang wrote:
Someone previously posted pretty good information about the format of CryptProtectData on MSDN. I think it should be possible to implement a close facsimile, except that the user's credentials (password) would be missing in Wine since there isn't any at the moment. If you have time to do this, it would be ideal. Failing that, doing any stateless transformation (e.g. no change at all, or xor-ing with some magic value) would be preferrable to storing this data in the registry, if I understood Alexandre's comments correctly.
Okay. The article (while very good: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/ht...) doesn't fully address the "opaque data blob". I have taken it apart and found some common lengths, etc, so I think I can produce a reasonable guess at it, so that the future implementations will have very little to change. The clues in the section "Protected data blob" is what I'm using for the guesses at the data blob format sections.
I should have a new patch ready soon. Luckily all the tests and documentation will remain valid. :)
We're trying to avoid proliferation of OpenSSL in Wine. Relying on CryptoAPI is a safer bet.
Is there somewhere I can find details on what's been completed in the CryptoAPI? The http://winehq.com/site/winapi_stats page say it's at "21%".
Thanks for all the clarification. I appreciate it!
On 5/3/05, Kees Cook kees@outflux.net wrote:
Is there somewhere I can find details on what's been completed in the CryptoAPI? The http://winehq.com/site/winapi_stats page say it's at "21%".
The easiest way to determine how much of CryptoAPI is implemented is to dig into the code and see what has been implemented. You can also look at the dll spec file to see which functions are 'implemented' and which are true stubs, where 'implemented' means either truly implemented or stubbed out (FIXME("stub\n") etc). Browsing the source will also help to familiarize you with CryptoAPI.