<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 8, 2016 at 8:37 AM, Natanael <span dir="ltr"><<a href="mailto:natanael.l@gmail.com" target="_blank">natanael.l@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 8 dec. 2016 2:10 em skrev "Phillip Hallam-Baker" <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>>:<blockquote class="m_-3308247764307666339quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>All documents should be signed but only confidential documents need to be or should be encrypted.</div></div></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">There's another problem too. Not all signatures should be permanent, nor public. </div><div dir="auto"><br></div><div dir="auto">Sometimes integrity and authentication needs to be ephemeral. Most people have already acknowledged that for IM (Signal), but seems to forget it (or at least doesn't mention it) as soon as the context is changed. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​Repudiable authentication is definitely useful. I am rather peeved that the TLS key agreement creates a non repudiable proof that there was a communication.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are a few ways you can achieve that in a bilateral communication. For example, do a key agreement and use the resulting key to key an HMAC, And you get that for free with authenticated encryption modes.​</div><br></div><div><div class="gmail_default" style="font-size:small">​What I do not know how to do is to achieve authentication without non-repudiation in a multiparty communication. ​That might well be because it is a contradiction in terms. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we have Alice, Bob and Carol all in a communication, I can key it so that they all have access to the same shared secret and they can know that a packet originated from a member of the group. What I can't do (efficiently) is to allow Bob to know that a message was authenticated by Alice in a way that does not allow Bob to show John that Alice wrote it.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The reason the HMAC scheme is repudiable is that Bob has all the information Alice does. Bob can't show John any information that Bob couldn't simulate from Alice's public key and his private key.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If Bob has the ability to simulate any authentication signal from Alice to John, Bob can do the same to Carol.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The only way that I can establish authentication in a group setting is either using a signature or with a set of n*n bilateral keys.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So right now, what I plan to do is to simply sign data using a fast Curve25519x signature.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If repudiation was desired, then each party would have to generate an ephemeral authentication key and provide a bilateral authentication on the ephemeral to each member of the group. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That would work for a synchronous conversation with a limited number of parties. But it would quickly become unwieldy if you had a chat with 100+ people. It certainly would not work for the set of all people with a NATO Confidential clearance.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">We could already just design a Signal protocol style 1-n party single-message authentication scheme, by essentially defining some specific way of sending a hash of the message to the intended recipients in the same way Signal initiates conversations. <br></div><div dir="auto"><br></div><div dir="auto">Mixed with time limited master keys and purpose-specific keys, it would drastically reduce the impact of data breaches. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​That is one of the things I am working on in Mesh/Recrypt which uses proxy re-encryption to support end-to-end encrypted Web (and more).</div> </div></div></div></div>