Re: authentication protocols
- Original Message - From: John Saylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 25, 2002 3:14 PM Subject: authentication protocols I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Depending on your exact requirements, there are many potential options. Let's start with the most basic: The parties securely exchange a verifier. There are many variations at this point, but the basic version is (with details omitted for brevity): A-B: I am A B-A: If you are A then you can decrypt this E(K) and use K as our shared key A decrypts and now both A and B share a one time secret This is generally done using symmetric keys More sophisticated, and scaling much better requires a trust model of some kind. This does however get very tricky. There has to be some verification of the key by a 3rd party (which can typically be the same as one of the first 2 parties). However it is possible to build something usable, as long as on one occasion you can verify the identity of the other party. This type of protocol works approximately as so: B has a verified public key for A A has a verified public key for B A-B: S(I am A, our temporary key is E(K), the current time is T) B verifies signature, and decrypts K, K is now the shared secret There are of course variations where it is E(S(K...)) instead of S(...E(K)...) There are many different variations on this, some patented, some unencumbered, some that are secure down to the use a an ATM-like PIN, some that require larger quantities of secret data, some that take 1 pass from A to B, some that take 10 passes between them, some that have nice provable reductions, some that don't. It all depends on what your needs are. But all of these require some trust model, and initial verification of the key is the problem. Moving over to situations where you are not forced to perform an initial key verification requires a trusted 3rd party, which is what you requested to avoid so I won't introduce them. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication protocols
John, Do your parties have any shared secret information? If they share a cryptographic key, they can use a simple hash-based challenge/response protocol. If the have shared passwords or any other small secrets, they can use EKE or SPEKE. There are lots of neat tricks that might be applicable, but you should first describe your needs in more detail. -- David At 06:14 PM 3/25/02 -0500, John Saylor wrote: Hi I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Most of the stuff in _Applied_Crypto_ requires that third party. It may be an impossible task, nothing seems obvious to me. Pointers, suggestions, or aphorisms all welcome. -- \js innovate scalable infomediaries - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication protocols
At 06:14 PM 3/25/2002 -0500, John Saylor wrote: I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] You want to look at the work of Carl Ellison and folks on SPKI It allows one party to authenticate the second. If that fits your case, and it fits a lot, then you are done. No CA needed. The SPKI stuff is at http://world.std.com/~cme/html/spki.html Pat Pat Farrell [EMAIL PROTECTED] http://www.pfarrell.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication protocols
On Mon, 25 Mar 2002, John Saylor wrote: I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Authentication relative to what? All identity, and therefore all authentication, derives from some kind of consensus idea of who a person is. With no third party, it is hard to check a consensus. Usually authentication comes down to checking a credential. But that implies some third party that issued the credential. So, the pertinent question becomes, what is identity? For purposes of your application, I mean -- no point to go off on philosophical tangents. Answer that, and maybe there'll be a protocol that you can use. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: authentication protocols
John Saylor wrote: Hi I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Most of the stuff in _Applied_Crypto_ requires that third party. It may be an impossible task, nothing seems obvious to me. Pointers, suggestions, or aphorisms all welcome. You need to specify what you are trying to achieve! For example, its easy to avoid third parties if you have already exchanged keys. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
authentication protocols
Hi I'd like to find an authentication protocol that fits my needs: 1. 2 [automated] parties 2. no trusted 3rd party intemediary ['Trent' in _Applied_Crypto_] Most of the stuff in _Applied_Crypto_ requires that third party. It may be an impossible task, nothing seems obvious to me. Pointers, suggestions, or aphorisms all welcome. -- \js innovate scalable infomediaries - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
