Chris Muller wrote:
Is everyone here saying that, despite having been around since 1976 (thirty years!), PKC best-practices are still so complex, dark and mysterious that we should not even attempt it?
Yes, apparently :-) I find it hard to believe, as well, but the advice from the experts is that there should be as few implementations of cryptographic toolkits as possible, to make sure that the few that exist are of exceptionally high quality.
There's a ton of stuff I personally just don't have the knowledge to guard against (such as timing attacks etc.) quite aside from the implementation of the primitives themselves, their properties when they are combined into higher-level tools, and the discipline required around such things as zeroing key buffers after use and so on.
OpenPGP, http://www.ietf.org/rfc/rfc2440.txt
With this we would send cleartext outside the image to this external, highly-complex, non-OO, differently-licensed, implicitly-trusted PGP module?
No, we would produce a Smalltalk-native implementation of the well-specified, well-debugged, implementation-neutral data and exchange format that is OpenPGP. It's a good spec; if you haven't read it, I recommend it.
(I don't see it as particularly complex, either: it seems to me to be the simplest-thing-that-could-possibly-work, almost (aside from such things as the old-fashioned preference for binary metadata).)
But, some of us just want real security, not official certifications.
That's why I recommend OpenPGP - it's a tested-and-true encrypted-and-authenticated-data format.
And implementing this complex spec will not eliminate the need for extensive critique and testing.
No, but it does eliminate the need for some design and design review, while also providing a certain amount of interoperability.
Anyway, it was just a thought. :-)
Cheers, Tony