Pluribus

Bill Frantz frantz@communities.com
Fri, 05 Nov 1999 14:16:59 -0800


I asked Hal Finney to take a look at the Pluribus protocol.  He has very
kindly given me permission to post this response.

From: hal@finney.org
Date: Thu, 4 Nov 1999 23:16:01 -0800
To: frantz@communities.com
Subject: Re: Pluribus

Bill - I looked at the protocol a bit; the only part I could understand
clearly was the low level comm protocol.  I do think there are some
changes you should consider in order to improve this.

I did not try to go through the logic of the handshake state machine,
as it was pretty complicated.  I believe the worst that could happen
here would be some possible race conditions or hangs if there is a glitch
in this logic, not a security failure.

The use of the DSS signature to authenticate the DH exchange plus the
earlier messages should address any security issues with regard to the
handshake, so that part looks good.

One thing which looked like it might possibly go wrong here is if the
man in the middle made each side think the other didn't want to use
any crypto, then no crypto would be used.  As I said I didn't have time
to trace it through in detail so I'm not sure this is possible

Even if so, both sides would know they aren't using security, so this
is not exactly a security flaw.  I don't know if you really anticipate
using unsecured links, but if you don't, you should consider making
the protocol fail if a secure link can't be established.  It's always a
little risky if an attacker can throw you into an insecure mode, even
if high level programs can detect it, because they may not check!

For the actual encrypted/authenticated data exchanged, I think what you
have is basically OK.  However I would suggest that you would do better
to copy the methods used in RFC2246, the TLS standard (essentially the
same as SSL).  Specifically there are three improvements:

 - First, instead of incrementing the IV each time, use the last ciphertext
   block of the previous message.  This is easy for you since you are
   building on top of TCP so you have sequenced and reliable transport.

   Inc'ing the IV is not really a problem as you use it, but as a general
   principle it is preferred to have it not be so similar from packet to
   packet.

   Generally, the danger in this practice occurs when the first block
   of plaintext stays much the same in two consecutive packets, because
   then you have similar input into the 3DES stage, which can give an
   attacker a foothold.  In your case, the first block of plaintext will
   include at least 5 bytes of MAC, which should be highly variable,
   hence you are actually not vulnerable to this problem with your current
   message formats.

   However it would be best not to rely on this peculiarity of the
   packet structure, since it is not obvious that this variability is
   so important for security purposes.  A future redesign of the system
   might re-arrange the order of the data in the packet, not realizing
   that it was endangering security.

   By doing the IV in the more conventional way you will be immune to this
   kind of potential problem.

   TLS includes a sequence number in the packet payload separately from
   the IV, to prevent replay attacks.  Relying on an incrementing IV for
   this purpose is not as strong.

 - The MAC structure which is used is Hash (key, data, key) which is OK,
   but HMAC is a preferred and standard method which is widely used today.
   Technically the prefix and postfix keyed hashes have some potential
   flaws, which HMAC is immune to.  HMAC is defined in RFC2104, and is
   analyzed (along with flaws in some of the other MACs) in "Keying Hash
   Functions for Message Authentication" by Bellare et al, Crypto 96.

 - It would be better to use separate encryption and MAC keys for
   the two directions, as is done in TLS.  This reduces the amount of
   ciphertext encrypted with a given key by half and also helps reduce
   problems relating to replay attacks where messages encrypted in one
   direction are legal when sent in the other direction.

All three of these points are based on the techniques of TLS/SSL.
This protocol was originally designed by Paul Kocher, who is one of
the best experts in the field, and it has withstood considerable review
and challenge.

I understand that you don't want to use TLS in all its gory details, but
I don't think it would hurt at all to follow the TLS conventions very
closely once you get to the point where you have the shared DH secret.
This is described in section 6 of the TLS spec.  6.2.3.1 describes
the MAC, 6.2.3.2 describes the CBC encryption, and 6.3 describes the
process for generating the cipher & MAC keys starting from the shared
DH secret value.

It may seem that TLS is more complicated than you need, but really your
requirements and theirs for confidentiality and tamper detection are the
same once the stream is set up.  It is probably not much more effort
than what you have now to generate a few more keys and perhaps have a
couple of extra counters.

Overall, I don't see any specific exploitable flaws in the current design.
So in terms of security, revising it would not be critical.  However it
would obviously be easier to make changes while the language is still
in relatively limited use.  I do think that it would be good to improve
the protocol along the lines I have suggested here, eventually.  At that
point you will have a truly first rate and state of the art encryption &
authentication layer that you can be very confident in.

Hal Finney
hal@finney.org