Re: [GNUnet-developers] key exchanges

[Christian Grothoff]

Hi Dominic,

I'm putting gnunet-developers in CC, as this is really where this ought
to be discussed.

You certainly wrote an interesting paper with many good points. I
especially like that the last variant of your protocol offers a version
switch without introducing a distinguisher into the wire protocol. What
I'm not convinced about is mostly that you do go back to using
signatures to avoid the "wildcard".  Signatures leave persistent
evidence: Alice did want to talk to Bob.  Bob can prove this to third
parties if he has Alice's signature. So this is no longer "off the
record", at least as far as the meta data goes. In return, you defeat
the "wildcard" attack, but the fact that Bob is really screwed if his
private key is "lost" sounds only "fair" to me -- Bob was compromised
after all.  OTOH, with your scheme, Bob can prove something about Alice,
which feels worse.

Maybe we can fix this by making Alice not sign with her own key, but a
derived key.  For example, Bob could send a factor x in the 2nd step
(together with the server's ephemeral key, already boxed in the
ECDHE-box of the two ephermerals). Then, like in GNS, Alice would derive
a new key pair A' = xA (via point/scalar multiplication of her long-term
private/public keys) and could sign with A'. Bob could use his knowledge
of 'x' to forge such a signature, so the signature is worthless and the
conversation stays metadata-OTR: Bob cannot even prove to a 3rd party
that he ever talked with Alice, and still even if Bob's long-term
private key is compromised, he could be sure that at this time, he was
talking with Alice (so no wildcard).


With respect to adopting anything like this for GNUnet, there is a bit
of an architectural issue that we'd have to solve first: right now, the
client (Alice) self-identifies to the server (Bob) in the clear on the
transport-layer long before the KX happens.  This is used to allow the
server to refuse the connection (before self-identifying as "Bob").
Compared to your handshake, it has the disadvantage that Alice reveals
her identity "in the clear" to the network (unless the HTTPS-transport
is used, in which case we should get your semantics with many more
round-trips).

The fact that GNUnet's existing transports are "below" the KX-crypto
means that they do leak a bit more information (such as Alice's peer
identity, cryptobox-boundaries, etc) than strictly desirable, which is
one of those "long-term" problems that has been in the back of my mind
for a while. The architectural reason for this was/is to keep the very
high complexity of dealing with many protocols separate from the process
that deals with the "sensitive" cryptography / key material.

So please disregard my comments from the camp that this would just
require changes to the KX logic in core, this would be a bigger change
to get the desired semantics.  I'm not against this happening (modulo
the signature vs. wildcard issue), but it is not the small change I
initially imagined.


Happy hacking!

Christian

On 08/18/2015 03:21 PM, Dominic Tarr wrote:
> hey,
> 
> here is my hand shake paper:
> 
> http://dominictarr.github.io/secret-handshake-paper/shs.pdf
> 
> Any comments on the paper would be most appreciated.
> 
> Dominic
>

signature.asc
Description: OpenPGP digital signature