On Thu, Dec 8, 2016 at 8:37 AM, Natanael <natanae...@gmail.com> wrote:
> > Den 8 dec. 2016 2:10 em skrev "Phillip Hallam-Baker" < > ph...@hallambaker.com>: > > All documents should be signed but only confidential documents need to be > or should be encrypted. > > > There's another problem too. Not all signatures should be permanent, nor > public. > > 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. > Repudiable authentication is definitely useful. I am rather peeved that the TLS key agreement creates a non repudiable proof that there was a communication. 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. 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. 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. 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. If Bob has the ability to simulate any authentication signal from Alice to John, Bob can do the same to Carol. 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. So right now, what I plan to do is to simply sign data using a fast Curve25519x signature. 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. 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. 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. > > Mixed with time limited master keys and purpose-specific keys, it would > drastically reduce the impact of data breaches. > 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).
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
