Well, I don’t. That is why I am spending a lot of time trying to learn how the pieces of cryptography that are being used by WSE work. And appreciating how hard the designers of the WS-Security and WS-Trust and WS-SecureConversation specs have worked out all of the what-if’s and come up with lots of cool ways to prevent them. Derived Keys are a great example of that.

But my problem is this: if you define a chair to me and said “well, it has a seat and 4 legs and a back”, I’m going to ask you what legs are and what is a back and what is a seat. That is exactly why I have been driving myself a little nutty with WSE2. Once I understand what legs are, how they were made and how they work, I am going to be a LOT more comfortable sitting in that chair.

Derived keys are made up of a combination of things. I need to know what these pieces all are and where they have come from, so I just keep reading and reading until I find an explanation that doesn’t just say derived key is made up of a few things and then move on. (Oh, if you’re curious, there are some great explanations: here and of course, here). Having looked this over, now I don’t mind just using the DerivedKeyToken class and passing it my security context token that I have created for a secure conversation and being done with it. (oh thank you Microsoft for WSE2)

I just don’t like it all being “magic under the covers stuff”. How about you?

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!