Found XMLSec Library listed on <?xmlhack?>.

Along with providing the actual XML Security library files (C libraries) designed to be used by other applications, the distribution also includes a command-line tool, xmlsec, for signing and encrypting documents.

This could solve my cyptlib woes for the time being.

5:38:22 PM  comment [] | Categories: JobFish Homework, My Organization, Work Projects| Topics: Cryptography XML 

Howard Newton. "People forget how fast you did a job - but they remember how well you did it." [Motivational Quotes of the Day]

So I located, downloaded, and compiled cryptlib. No errors! Next I compiled testCryptLib. No errors! Next I ran testCryptLib. Errors. That's just great.

I could go ahead and write the code that calls cryptlib, then present my prototype with the disclaimer that cryptlib's self-test program currently fails, but when that is ironed out, here is how we will call it. Does that seem shifty? It's going to sound like "here is the program. It doesn't work, but it is done."

Looking at this another way, presenting the flawed prototype keeps the superiors apprised of the project status. I hope nobody panics when testCryptLib doesn't pass (yet).

3:24:28 PM  comment [] | Categories: JobFish Homework| Topics: Cryptography XML 

Jon Udell is opening a can of worms, I must not look...

I always knew there were ways to encrypt information and I accepted that. Then I was assigned the task of revamping our software licensing process. This required me to choose an encryption method. Choosing an encryption method required me to justify my selection against its alternatives. Justifying my selection required me to understand both my selection and the alternatives that I did not choose.

So I did some reading, and once I understood the difference between Private Key Encryption and Public Key Encryption, I changed my mind. Public Key Encryption surely seemed like the better choice.

If some rogue ex-employee were to take the private key and issue passwords for a discounted price, we could throw out the old key pair and replace it with two new keys. Because one of the keys of the pair is public, we could simply distribute it along with the encrypted information. No need to hard-code the private key in the software, right? No need to require customers to reinstall existing software, right? No need to maintain legacy password generation programs, right? (Anyone who has done this before, please comment...please throw me a clue...)

Yes, I thought I finally had gotten it. Public Key Encryption provides more convenience, more security, more robustness than Private Key Encryption.

I am trying to resist looking at Jon Udell's post. He is questioning his long-held assumption that Public Keys were the way to go.

Remind me why I need a public key. Dick Hardt, founder and now CTO of ActiveState, was prowling around the digital ID conference asking a deceptively simple question: "Why do I need a key pair?" ...

[Jon's Radio]

2:05:29 PM  comment [] | Categories: JobFish Homework, My Profession, Work Projects| Topics: Cryptography XML