I want to thank everyone for the KryptOn 1.0 comments. A couple of improvements have been identified (getting rid of that ECB mode and using "associated data"..) and that helps immensely. I will work on these and post an update soon. But my hope is that KryptOn will, going forward, be community-developed so that it has the benefit of everyones collective knowledge.
I racked my brain for months trying to account for insidious attacks such as "replay attacks" and believe I have this sort of attack (among others) solved. The result is what I hope is a "good start" that can be "taken over" by the community with more crypto knowledge.
I also spent a lot of time accounting for the *usability* of KryptOn. For example, it absolutely omits API that pretends to solve the initial-key-exchange problem. That's why API is provided only to export to a file, not a Stream (i.e., SocketStream), and the instructions say to exchange "in person or via a trusted third party." Usability is an area where I think my skills bring something to the table.
My goal is for Squeak to have an OO security solution that is easily groked, critiqued, fixed and used.
I know there is no "absolutely" secure remedy (except maybe one-time pad) but, in terms of the levels of gray, I know Magma has gone from completely white (insecure) to some shade of dark gray. Deep down, I believe it is now, at a minimum, "secure" from the population that are not cryptanalysts (I myself couldn't begin to plan an attack against a running server). This is worth something isn't it? To me, it is.
I guess I'm quite surprised by the "fear and mystique" surrounding implementation of basic PKC protocol. 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?
Would it make sense, for instance, to have a Smalltalk implementation of OpenPGP, http://www.ietf.org/rfc/rfc2440.txt ? It's good for encrypting and signing messages, all the design's been done, it's widely implemented, and it has already been *extensively* analysed. Could KryptOn become an OpenPGP?
With this we would send cleartext outside the image to this external, highly-complex, non-OO, differently-licensed, implicitly-trusted PGP module? Maybe there is a place for that sort of solution to pacify corporate interests that want the "certification" assurance. But, some of us just want real security, not official certifications. As software developers, we can feel confident with our own work because we understand it all the way down and it has been reviewed by our peers whom we trust.
And implementing this complex spec will not eliminate the need for extensive critique and testing. And it does nothing for capabilities authorization, which KryptOn provides now.. So how about start with KryptOn, a pure OO solution, apply the design principles in that OpenPGP spec, "rip KryptOn to shreds" so we can then patch it up together, as a commmunity, and all learn something in the process..
The pure-OO solution is an opportunity for us take charge of our own software-destiny and to "document," via high-clarity implementation, a secure way to do PKC protocol with objects once and for all..
Andreas expressed an interest in KryptOn for Croquet security (http://minnow.cc.gatech.edu/squeak/5838). Only the cryptography team, *as a community*, can have the knowledge and clout to help the Croquet team out.
I'm asking for help, I want to move forward with KryptOn. I'm ready to add any of you to be developer on KryptOn to the SqueakSource project.
Best Regards, Chris
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
cryptography@lists.squeakfoundation.org
-
Chris Muller -
Tony Garnock-Jones