Double Ratchet & Revealing Mac Keys about otrv4

[yakiradixon]

Aren't we a bit off base here with some of this conversation? This issue is about when and how we should reveal MAC keys with double ratcheting.

I'm still gathering my thoughts around this. I think double ratcheting's out-of-order resilience makes it a bit more difficult to determine when an old MAC key (a key that will no longer be used to verify that a message is authentic) should be revealed.

[tcz001]

Previously OTR3 use ratcheting relying on acknowledgement from message receiver, and revealing Old MAC keys when your are about to forget either one of your old D-H key pairs, or one of your correspondent's old D-H public keys according to Revealing MAC keys section

In OTRv4 we can always get a message with Message Number, so if both sides keeps increasing Message Number in ratchets, there won't be any duplication (no reuse of Enc/MAC keys), which means we can directly reveal a MAC key once we receive and verified a data message successfully.

This can provide forgeability once MAC key is revealed in the channel, anyone has access to this MAC Keys will be able to forge data messages in transcript.

[rosatolen]

Double ratcheting has weaker message forgeability properties than OTR.

See "Deniability" section of this paper: >https://eprint.iacr.org/2014/
904.pdf

The paper says:

To conclude the discussion, the design of the TEXTSECURE protocol
achieves deniability on a protocol level.

However, in practice the following happens: when a party sends a message,
it needs to do so via the TEXT- SECURE server. The message itself is
encrypted, but in order to guarantee correct delivery, the identities of
the sender (regIDa ) and recipient (regIDb ) have to be transmitted to the
server. The sending request is authenticated with the sender’s phone number
and password.

The server is not able to read the content of any message and handles only
the delivery. Therefore no one can prove— even if the server
collaborates—which content was sent. However, one major goal regarding
deniability is the ability to plausibly disclaim any involvement in a
conversation or to deny having a conversation to some party at all. Looking
at the delivery procedure of TEXTSECURE , this goal is not achieved if the
server logs all delivery requests.

In conclusion, TEXTSECURE only achieves deniability theoretically. Content
deniability is provided due to our security proof but we can not prove that

no delivery request will be recorded at the TEXTSECURE server.

The paper only says server logging destroys deniability of TextSecure in
practice. How does that mean the double ratcheting has weaker message
forgeability?

[claucece]

I guess it should say that 'TextSecure in practice has weaker deniability', if we define deniability as 'message repudiation' and 'participation reputation', like in this paper. Following this definition, we can see on the graph of page 11 that double ratcheting provides message repudiation and partially provides participation repudiation. If we combine it with 3-DH AKE, we then provide both message and participation repudiation. 3-DH achieves participation repudiation since anybody is able to forge a transcript between any two parties by generating both a_e and b_e and performing DH key exchanges with g^a and g^b.

[chelseakomlo]

The paper only says server logging destroys deniability of TextSecure in practice. How does that mean the double ratcheting has weaker message forgeability?

In OTR, because MAC keys are published, this means that anyone intercepting the ciphertext can forge the message.

With TextSecure, message deniability is based on the fact that the other party can forge the entire conversation. While the conversation can still be entirely forged, it can only be done by the other person in the conversation, rather than anyone with access to the ciphertext.

[rosatolen]

Anyone can forge a TextSecure transcript, not just the person participating
in the conversation, as long as they have the public keys of the two
parties they want to frame and they generate two Diffie Hellman ratchet
keys.

Actually, moxie0 argues here that OTR only allows people who have talked
with you to create the ephemeral keys to forge a conversation. Not anyone
can do that. Ref.:
https://whispersystems.org/blog/simplifying-otr-deniability/

El martes, 20 de septiembre de 2016, Chelsea Komlo [email protected]
escribió:

The paper only says server logging destroys deniability of TextSecure in
practice. How does that mean the double ratcheting has weaker message
forgeability?

Because in OTR, because MAC keys are published, this means that anyone
intercepting the ciphertext can forge the message.

With TextSecure, message deniability is based on the fact that the other
party can forge the entire conversation. While the conversation can still
be entirely forged, it can only be done by the other person in the
conversation, rather than anyone with access to the ciphertext.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#44 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACS6nvt5sQpd0nuXSgrGYYd1__fCQtq1ks5qr9_JgaJpZM4KBEuP
.

Rosalie Tolentino

Pure EnergyShe/Her They/Them
Office San Francisco
[email protected]
Telephone[phone]
[image: ThoughtWorks] http://www.thoughtworks.com/
Fingerprint: 55A0 392B C270 DEBD 6842 A1A7 682A BA98 875D 87B9
This communication may be unlawfully collected and stored by the National
Security Agency (NSA) and/or its allies in secret. The parties to this
email do not consent to the retrieving or storing of this communication and
any related metadata, as well as printing, copying, re-transmitting,
disseminating, or otherwise using it. If you believe you have received this
communication in error, please delete it immediately.

[chelseakomlo]

My understanding is the difference between the term anyone.

TextSecure relies on the fact that two parties have a secret symmetric key for the double ratchet. So one side can forge the entire transcript, but this is different than what OTR achieves by publishing MAC keys, which means that the single message corresponding to that published MAC key can be forged.

From an OTR mail: https://lists.cypherpunks.ca/pipermail/otr-dev/2013-February/001645.html
The transcripts in question here are the ciphertexts; that is, Eve just
does a packet capture on the wire. She does indeed get access to the
MAC keys, but not the decryption keys. Then Eve can use the OTR
toolkit that comes with the OTR software to modify the transcript so
that even if Bob provides the decryption keys, it will decrypt to
whatever she likes. The goal is to make OTR transcripts just as
forgeable as plaintext transcripts. If OTR had instead used, for
example, PGP-signed messages, this would not be possible, and Alice
would not be able to repudiate what she said in confidence to Bob.

So it seems that moxie0 is extending the fact that someone can forge an entire transcript in TextSecure to that someone can forge a single message, (which is probably true) but it doesn't seem to be equivalent to what OTR tries to achieve by publishing MAC keys.

[chelseakomlo]

Actually, moxie0 argues here that OTR only allows people who have talked with you to create the ephemeral keys to forge a conversation. Not anyone can do that.

That is because of the outer DH channel wrapping the AKE. This should be looked at in the #11 discussion.

[rosatolen]

That's fair. We should take the discussion about deniability of TextSecure
somewhere else.

But the article I mentioned before has a section called Limited
Forgeability which talks about how a forger cannot take the revealed MAC
keys and generate an actual conversation where the plaintext can also be
revealed.

I've been trying to figure out if it's safe to release the encryption and
the MAC keys of the ratchet before the previous ratchet and whether that
would give us more participation deniability than releasing just the MAC
keys.

El martes, 20 de septiembre de 2016, Yakira Dixon [email protected]
escribió:

Aren't we a bit off base here with some of this conversation? This issue
is about when and how we should reveal MAC keys with double ratcheting.

I'm still gathering my thoughts around this. I think double ratcheting's
out-of-order resilience makes it a bit more difficult to determine when an
old MAC key (a key that will no longer be used to verify that a message is
authentic) should be revealed.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#44 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACS6nkl1g7co80A21AqaY5ERW7OjR1Uaks5qr-gqgaJpZM4KBEuP
.

Rosalie Tolentino

Pure EnergyShe/Her They/Them
Office San Francisco
[email protected]
Telephone[phone]
[image: ThoughtWorks] http://www.thoughtworks.com/
Fingerprint: 55A0 392B C270 DEBD 6842 A1A7 682A BA98 875D 87B9
This communication may be unlawfully collected and stored by the National
Security Agency (NSA) and/or its allies in secret. The parties to this
email do not consent to the retrieving or storing of this communication and
any related metadata, as well as printing, copying, re-transmitting,
disseminating, or otherwise using it. If you believe you have received this
communication in error, please delete it immediately.

[chelseakomlo]

To have for reference- from the OTR paper, section 4.4, describing what we achieve by publishing MAC keys:

Note what this has accomplished: Bob doesn’t need to
rely on this key any more, since he’s already checked all of
the messages authenticated by that key. However, now
anyone can create arbitrary messages that have this MAC key,
and no one can rule out any particular person as a potential
author of the message. This can be seen as the analogue
of perfect forward secrecy for authentication: anyone who
recovers the MAC key in the future is unable to use it to
verify the authenticity of past messages.

https://otr.cypherpunks.ca/otr-wpes.pdf

[chelseakomlo]

Hi, this is useful also: https://lists.cypherpunks.ca/pipermail/otr-dev/2013-July/001801.html

[tcz001]

About when to reveal MAC keys,

A receiver can always reveal a MAC key directly after verified this message.
But receiver should not use/accept the revealed MAC key anymore.

A sender would have different scenarios:

1. the message is received and MAC key is revealed, which is fine
2. the message is received but MAC key is not revealed
3. the message is not yet received

The second and third scenarios are kind of conflict, because it appears the same for a sender while no any acknowledgement announced from receiver.

In this case, we need to give the sender something like a expiring preference to reveal a MAC key by itself when he decide the message is no more useful, regardless whether receiver has received and verified or not.

[olabini]

OK, about Moxie blog post, there are two problems with that logic. First, as far as I can tell - you don't NEED a signed ephemeral key to create a valid transcript, since the only thing that is necessary to create a valid transcript is the shared secret. But as we have talked about before, there is a difference between participation deniability and content deniability. OTRv3 is weaker on participation - one of the reasons we are upgrading to a DAKE.

The other argument is that MAC keys are not enough to create valid plaintext, since you still need to have the content keys, thus the only person that can forge is still the other participant. The problem here is the difference between forging and denying. Forging implies that someone crafted a plaintext message to be exactly something else, while deniability means you can argue that someone else changed the plaintext. Thus, with the MAC keys revealed, that means there are more people that could have interfered with the ciphertext - which means the deniability gets stronger.

[tcz001]

So we now agree that Revealing MAC keys is doable and also reasonable according to the discussion.
I'm taking the notes that this feature can provide us:

• Content deniability, when more people have access to revealed MAC keys.

For fitting this feature in double ratcheting, we have a proposal of:

• Sender can reveal MAC keys after decrypt & verify each message.
• Receiver can reveal MAC keys when decide to abort the corresponding message (can be a expiry policy) we have concern about this idea, because it will break the authentication of sender and make the message forgeable before receiver read this message.

[tcz001]

Related with #11 , if we decided to do super-encryption, we still want to reveal MAC keys as plaintext outside of the super-encryption layer.

Because, if QC break the DAKE and inner Data Message, PlainText MAC keys will be known by the attacker. In this case, revealing PlainText MAC key, compared with CipherText MAC key, will be a better choice to avoid chosen-plaintext-attack.

[tcz001]

Question:

Now we have decided In-Order network model, should we use Double-ratcheting?
If we use double ratcheting, does our proposal provide the same deniability property that old OTR versions gives in regards to Revealing MAC key?

Answer:

Yes. we can achieve same deniability as OTRv3 by Revealing MAC key in double-ratcheting.

From OTRv2-3.0.0 to OTRv2-3.1.0, the spec changed "Revealing MAC key" section due to the vulnerability "3.4 Message Integrity" mentioned in the paper.
Only receiving MAC key should be revealed by receiver to avoid this vulnerability.

In double ratcheting, we propose Revealing MAC key to be per message received, which provides same deniability as OTRv3, but per message instead of per key-pair-rotation.

This model needs to trust receiver to reveal MAC keys, that assumption doesn't change from OTRv3.

In that paper, there's also another proposal of avoiding this vulnerability without weaken deniability by revealing Sending & Receiving MAC keys corresponding to the keyid - 2 generation key-pair. But we need to consider how to achieve this in double ratcheting.

[tcz001]

If we want sender to reveal the mac key, we need:

1. in-order network model should always reject the messages which are:
   1. two-generation old (two ratchet before)
   2. having smaller message id(counter)
2. the sender would reveal either:
   1. each MAC key in that generation(ratchet)
   2. original chain MAC key of that generation(ratchet), from which all other MAC keys in that ratchet can be derived

This solution is fixing some problem but still not quite sound because MAC keys will be held for a longer time and it increase complexity of key management.

[yakiradixon]

I want to jump in and add to recent comments from @tcz001.

We drafted our proposal around revealing MAC keys with the assumption that we would be using double ratcheting. This was before any assumptions about the network model were specified.

When we decided to hold the assumption that messages are delivered in order, the value of using the double ratchet was brought into question. If we want to use it, what benefits do we get from it? And does our proposal for revealing MAC keys in the double ratchet make sense? Are we confident that it will work?

After some discussion yesterday, we concluded that we'd like to stick to using the double ratchet. We get the benefit of additional forward secrecy. We're also confident that our proposal for revealing MAC keys will work. It only works for a model that assumes in-order delivery of messages, though. We couldn't think of a sensible way to do this if we handled out-of-order messages.

In our proposal, the receiver is given the responsibility of publishing MAC keys in the next message that they send. We realize that this isn't ideal (one receiver could fail to reveal keys, and the full set would not be revealed). If we can think of something better, we'll modify our proposal.