community-developed KryptOn

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
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

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
--
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: [hidden email]
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography