ASK ToolKit Clarifications

["Myron Lewis" <mrlewis@keygen.com>]

I thought I would write one answer to all instead of getting embroiled in a
number of individual engagements.

I know that the claims we make for the ASK ToolKit(TM) sound a little too
good to be true.  In fact, someone I have been talking to for a while about
other subjects and who I thought respected my views told me that "If it
sounds too good to be true, it probably is-- too good to be true. "

But I have been on the same end of other controversial products and in the
final analysis was vindicated because the product worked as advertised --
even better.  I wouldn't lend my name to a "Snake-Oil" product.  I don't
need that kind of aggravation -- I'm too old.

Let me clarify what the toolkit is and what it isn't.

Unfortunately, I cannot talk about those things that are being patented, but
maybe in the near future.

The ASK ToolKit does not do encryption.

It only provides keys on demand for encryption.   These keys are
synchronized  across a communication link without the keys or information
about them being given out.

The keys are both random and unpredictable -- meaning that you will not be
able to deduce what the next key is even if you have any key that was used
in the past.   The system does not depend on the secrecy of internal
algorithms for security.

The ASK ToolKit does not "manage keys",  it just generates them on demand.
The developer can do what he/she wants with them.  To me, managing keys
means distributing them to the appropriate users (with authorization) or
moving them around outside of an application.  That never needs to happen in
an application using a symmetric system.  The ASK ToolKit can be used in a
Public-Private system, but that's a waste.

We are not blindly implying that applications using the ASK ToolKit are
unbreakable.  However, the toolkit provides the means for intrusion
detection and prevention.  We know of no method this simple that does that.

The toolkit provides a number of bells and whistles to allow the developer
of an appliction using it to do many things like change keys as often as
wanted -- even every bit (not practical) or re-synchronize (which is
different from re-initializing).  It also allows the last session
information to either be stored in encrypted form on the machine or removed
to a portable medium.

The ToolKit does not provide the initial strong authentication needed to
start the process off.  There are many very good methods for doing this, so
why should we bother.  These range from formal encrypted methods like
Diffie-Hellman to simple things like telephone calls, distributing floppy
disks to users, filling out online applications where the other side already
has critical information about the user, etc.   One thing that these shared
secret methods have going for them is that they can occur spontaneously --
random in time.
That is one of the best means of security.

The use of a shared secret with an application containing the ASK ToolKit is
only necessary once for initialization.  After the first Master Recovery Key
(which can be thrown away immediately), there is no relationship to the
shared secret and therefore the shared secret needn't remain secret.

Short of real clairvoyance, there is no method of determining to 100%
certainty that someone is who they say they are.  All methods suffer from
this first-time syndrome.  It's what comes next that is important.  Even
that first CA needs to be authenticated.  The ToolKit just cuts out the
subsequent CA fetching process which for large systems of users who need to
communicate often (more than once) can be overwhelming.

The claims we make are not so much for the ToolKit itself but for the
applications that we envision can be developed given the ingenuity of the
developer.    We invite everyone who has a genuine interest in possibly
using the ToolKit,
and who is not just tossing flame about, to contact us with their questions.
If you are a responsible consultant or represent a responsible organization
and can sign an NDA, then we would be glad to fill in the details.

Myron Lewis
President
KeyGen Corporation
The Key to Secure Communications(TM)