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)