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.
Date: Thu, 4 Nov 1999 23:16:01 -0800
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
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
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
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. 22.214.171.124 describes
the MAC, 126.96.36.199 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.