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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
