Cryptography Options: bcrypt.lib v. crypt32.lib

Apr 26, 2013 at 6:21 PM
I expect a more flexible approach to encryption/hashing/signing/etc. would be worth the effort on platforms where it can be plugged in. How are the architects of Casablanca seeking to keep those options open (e.g. facilitating use of CNG)?

Aside: Great work and very much appreciated!
Apr 26, 2013 at 6:31 PM
Just so that we have the context of your request -- more flexible than what? Right now, Casablanca doesn't really do any of that for you.

Apr 26, 2013 at 7:15 PM
Yes, I see you are only using it for conversion to/from base64. Currently you have calls to CryptStringToBinaryW & CryptBinaryToStringW in asyncrt_utils.cpp to support the conversions.

Aside from HTTPS with certs, I currently didn't know how far down these (crypto) roads you plan to go - I wasn't sure that you had or hadn't made a decision with respect to preferred hooks to cryypt32.lib to the exclusion of bcrypt.lib.

As to my own use: While I see the usual goal of RESTful APIs to include open and accessible messages, there are always offenders like myself who have extra needs - and yet can't justify dropping down to SOAP (clients would hate me) - I just need to inject a little shim here or there sometimes. And I'm always on Windows 8 or Server 2012.
Apr 26, 2013 at 8:43 PM

Have you looked at the http_clien::add_handler() functionality? It allows you to insert code to process messages as the go out and come back, more or less arbitrarily. There are examples of their use in the pipeline_stage_tests.cpp unit test file.

Let us know if that is not sufficiently pluggable for your needs -- extensibility of this kind is really important, and add_handler() has been our standard solution to it. Another common use is to add a standard set of headers to each outgoing message, or strip returning messages of headers.

Apr 26, 2013 at 8:52 PM
Edited Apr 26, 2013 at 9:03 PM
Thanks Niklas - I hadn't gone that far yet - very nice - will give it a whirl!