Article 3354 of comp.lang.java.security:

I've recently completed most of the documentation for a protocol that can
be used to provide a secure, authenticated communication channel, and I'd
like to invite comments on its security. I will be writing an implementation
in Java, which should hopefully be available within a month or so. The
protocol will not be patented, and the implementation will be freely
redistributable (internationally, since I'm based in the U.K.).

Here is an excerpt from the web page, at
  http://www.users.zetnet.co.uk/hopwood/crypto/sid/

(note that the page is written as if the protocol has no flaws; don't take
that too seriously, since obviously one of the reasons I'm posting here is
so that people can try to find flaws in it).
----

SID authentication
~~~~~~~~~~~~~~~~~~

SID is a method for handling authentication using public key
cryptography. Each user has a public key, but each pair of users who
communicate regularly also know each other by separate "pseudo-public"
keys. A pseudo-public key is a public key that is treated as a shared
secret. 

The name SID stands for "Security in Depth", i.e. the principle that secure
systems should be layered, in such a way that breaking one layer does not
automatically allow any of the others to be broken. For example, in
protocols that use session keys, breaking a session key normally only
compromises the data sent in that session, not other sessions. This is
obviously a good thing, and the protocol described later tries to extend
similar properties to other kinds of attack. 

Suppose that Alice communicates regularly with Bob. SID has the
following properties that are not true in general of protocols that provide
authentication and secure channels: 

  o  Alice requires a private key in order to connect to Bob. Suppose
     that Eve has captured this private key, and has used it to pretend to
     be Alice. The next time the real Alice attempts to connect to Bob,
     she will detect that someone has impersonated her (and similarly
     with Alice and Bob exchanged). 
  o  Even if both current private keys have been compromised, if the
     real Alice and Bob communicate using this protocol at a later time
     without a man-in-the-middle, they will detect whether one or both
     of them was impersonated. 
  o  A passive attack on the protocol, i.e. eavesdropping a session and
     attempting to determine what was sent over it, requires breaking
     either a random public key or the session key, for each session.
     This applies even if all the keys that have ever been stored by Alice
     and Bob (as opposed to temporary keys held in memory) are
     known to the attacker. 
  o  Alice does not possess the information necessary for anyone to
     fool her into thinking they are Bob, or vice-versa. 
  o  The key exchange protocol is designed not to encrypt any plaintext
     that could be known to an attacker, with any key. Each block of
     input to the public key algorithm is unpredictable and uniformly
     distributed. Also, nothing is encrypted using a private key, so no
     additional information about any private key is available to a
     cryptanalyst. 
  o  For the body of the session, after key exchange, an encryption
     mode is used that combines a block cipher and a stream cipher to
     make known or chosen plaintext attacks much more difficult. A
     more detailed analysis of this mode is given here [link]. 
  o  In order to perform a man-in-the-middle attack, i.e. where Alice is
     connected to Bob but an attacker can intercept and change
     messages, knowledge of two private keys is required, one that is
     normally held only by Alice and one normally held only by Bob. 
  o  After Alice and Bob's first session, the corresponding
     pseudo-public keys are themselves secret. I.e. without
     eavesdropping the first session, even someone who can easily
     break the public-key algorithm cannot get any farther without
     breaking a session key, or finding the pseudo-public or private
     keys by non-cryptanalytic means. 
  o  Pseudo-public keys are changed once per session, so the previous
     statement can be generalised: without eavesdropping session n,
     even someone who can easily break the public-key algorithm
     cannot attack sessions n+1 or later, except by breaking their
     session keys or obtaining keys by non-cryptanalytic means. 
  o  Because separate pseudo-public keys are used between each pair
     of users, Bob cannot cheat and impersonate Alice to another user,
     even if he finds the private key Alice uses to connect to him. 
  o  The time between sessions can be used to determine a level of
     paranoia against attacks on the public-key algorithm (for example,
     factoring the modulus in the case of RSA). If the time between two
     sessions exceeds the paranoia setting, a dummy session can be
     inserted to change the current keys. This means that the time
     available to crack a pseudo-public key in order to try to
     impersonate Alice or Bob, or to perform a man-in-the-middle
     attack, can be limited to whatever is desired. 
  o  To try to make man-in-the-middle attacks using compromised
     private keys more difficult, there is a protocol (which can be
     initiated at any time during a session) that forces communication to
     take place in simultaneous rounds. For example, Alice and Bob
     can simultaneously pose a list of questions to each other, then
     simultaneously answer them. This prevents automated MITM
     attacks using a simple computer program, since the
     man-in-the-middle needs to guess Alice and Bob's responses
     sufficiently well to fool both of them. 
  o  Optionally, protection against limited denial of service attacks can
     be implemented. If an attacker can insert records, change them, or
     cause them to be dropped, but some proportion of records get
     through correctly, the connection can continue uninterrupted using
     the remaining bandwidth. For this to be useful, other
     denial-of-service attacks on the underlying transport should also be
     plugged. 
  o  Any combination of public key encryption algorithm, block cipher,
     and stream cipher may be used. Algorithms and key lengths can be
     different from session to session. For example, this allows the
     pseudo-public key length to be increased over time, to take into
     account improvements in computing power or factoring algorithms.
     It also allows algorithms (either public- or secret-key) whose
     security has been found to be in doubt to be dropped with a
     minimum of hassle or risk. 

These statements rely on each user's software being worthy of that user's
trust. A cryptographic protocol cannot prevent, for example, a Trojan
being installed on a user's machine that captures the plaintext of every
transmission, or modifies the user's keys. Given that assumption, though,
few if any other authentication systems provide comparable security
against attacks that involve private keys being compromised. 

David Hopwood
david.hopwood@lmh.ox.ac.uk, hopwood@zetnet.co.uk
http://www.users.zetnet.co.uk/hopwood/crypto/