For my comments on snakeoil see: http://crecy.ai.mit.edu/snakeoil/ Follow the navigation bars through 'key distribution" to "Monkey Wrench" Despite the hype KeyGen does not "throw a monkey wrench" into anything. It is unfortunately nothing particularly new. It is simply an example of the type of technique that is commonly used in conjunction with a public key system to keep keying material fresh while avoiding additional public key exchanges.
Unfortunately, I cannot talk about those things that are being patented, but maybe in the near future.
I hope you are not about to claim a patent on the use of one way hash functions to create keying material. I have prior art on that dating back to 1993 and I wasn't the first to discover it by a very long chalk. I suspect that the internals of Photuris probably contains most of the KeyGen proposal.
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.
What about hard coded internal parameters? If you can avoid the need for an initial insecure exchange your magic box means you don't need the synchronisation technique at all.
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.
I know of many, the problem is that most of them arn't much good. The only exceptionaly simple schemes I know are Diffie Helleman and RSA. D-H is certainly simple. It is astonishingly simple in fact and much easier to explain to someone than MD5 or SHA.
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.
OK how about the symmetric key exchange system from Shen? You already have exchanged a private key S beteeen the parties (e.g. used public key or you have a password established). You don't want to exchange the password over the wire en-clair of course. Nor do you wish to use the shared secret as the encryption key over long periods of time. One option is for party Alice to chose a random session mask M and send Bob M, The session key is then K = M XOR S. If the encryption system used is secure both parties can use the derrived session key without problems. A better solution however is for Alice to chose a random token R and send Hash (K, R), R to Bob. She can also use the XOR mask trick as well to decouple key exchange and session key choice. This is a massive advantage if the text you want to exchange has already been encrypted. i.e. we calculate M = K XOR S rather than chosing M at random.
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.
BECAUSE YOU GREAT PUDDING HEAD THAT IS THE ONLY HARD PART. Techniques to keep symmetric key material fresh indefinitely have been known for years. Kerberos is full of them. So incidentaly is Windows NT which happens to have a lot of similar ideas at least with respect to authentication. The GSSAPI probably has the same stuff burried inside it somewhere.
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.
This is the whole big problem. Most people I know who are interested in security worry about the competence of their security expert. So the obvious thing to do is to hire another security expert to audit their work. That is not possible if there are NDAs. Signing an NDA to not reveal source code is one thing, signing one to not use a mechanism is quite another. The capabilities you describe can be easily performed using conventional techniques. The only case in which NDAs normally come up in security work is when actual source code is being exchanged. Even then the norm is for the provider of the security toolkit to be providing their their trade secret source to the purchaser rather than this happening the other way round. As for licensing terms that relate to the utility of the functionality rather than the cost of doing the work these tend to be limited to cases where the selling party has an established product of known quality protected by credible patents. Jim Bizdos meets these criteria, you do not. Phill