Very interesting. But I have some questions. > Next, logon as each given user so it has a profile, load a PKCS#12 > certificate into their respective Personal store so they have > a public and > private key, and load the X509 public keys of all the others > users as well. > Of course you must include CAPICOM (the CryptoAPI COM wrapper > for Win32, > there is no .NET equivalent yet so you have to do Interop) in your > distributions.
What advantage do you see certs giving you over regular keys? > For each communication, envelope the data with the public key of the > intended recipient and dump it into the respective queue. What do you mean by envelope? Sign? Encrypt? > Now you're using MSMQ for your "remoting channel", but you get the > advantages of disconnected and asynchronous and > fault-tolerant delivery. > Set up MSMQ to use TCP, and you can do things like put an ISA > server (or > equivalent Cisco hardware) in front of the MSMQ receivers to > take care of > load balancing and etc. You also get additional security > "for free" because > the certificates you create can be as huge as you want > (16384-bit?) since > you control both ends of the handshake. How does increasing the key length from 1024 bits increase security? Are you relying on MSMQ channel encryption? > I have a project in progress for doing some secure > transmission, and I am > doing something along these lines. My message-sender takes > some data and > encodes it and then signs it with the sender private key, and > puts both in > CDATA sections. Then it envelopes the whole thing with the > receiver public > key, and drops that into a CDATA section in an XML document > with some extra > handler info That gets compressed and stuffed into a message > body, the > label has my app-specific info in it. Then it goes into a > remote queue. > The queue trigger (MSMQ2.0 on Win2K) starts up on the > receiver, decompresses > the message, uses the receiver private key to de-envelope and > the sender > public key to verify the signature and then back down to the original > content. It is working pretty well. You're not really encrypting the whole message with the receiver's public key, are you? That's got to be horrendously slow. And what does it buy you above and beyond MSQM channel encryption? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
