Hi Harlan,
On 2014-10-26 23:08, Harlan Lieberman-Berg wrote:
On Sun, 2014-10-26 at 21:22 -0400, Filipus Klutiero wrote:
Rather than advertising 2 independant items, these could be merged in a
"Deniable authentication" item which would contain both sublists.
One reason why I think "deniability" is important as a separate feature
is that it is differentiating in the face of other, similar kinds of
programs. Most encryption systems are not deniable; in fact, many
systems are not deniable /by design/. This message, for example, is PGP
signed and is not deniable at all. Anyone who gets a copy of the
message can verify that I, or someone with control over my private key,
composed and sent this message. The Pidgin-Encryption plugin similarly
doesn't have deniability built into its threat model at all.
I agree it is an important feature...
In that context, I think it might be deserving of being listed as its
own feature.
I didn't mean it doesn't "deserve" being listed on its own. What I meant is
that I consider it a subfeature of authentication, so I find it confusing to see it
independent from authentication. Grouping would make it more understandable.
By the way, I do not understand what "Anyone can forge messages after a
conversation to make them look like they came from you." means.
It's part of the deniability feature. While it's very difficult for an
attacker to forge a signature while the conversation is going on, the
ephemeral key used for signatures is publicly revealed after the
conversation is over. That means that you could forge any messages, and
theoretically, provide some defense against someone who /did/ manage to
compromise the communication being able to prove that you said what you
said.
Thank you, I now understand what this sentence is about.
I am not convinced this is a good thing, but for sure the current phrasing is
incorrect. According to the technical paper, OTR would merely send the key to
the other participant, so only him could forge messages, unless someone
captured the message. So the only person who can forge messages after the
conversation is the other participant. Since he could already forge messages,
that measure does not increase deniability in normal circumstances.
It is also unclear what "after a conversation" means. When does a conversation
end? In any case, the technical paper doesn't say keys are revealed after a conversation.
It is confusing to write that "However, _during_ a conversation, your correspondent
is assured the messages they see are authentic and unmodified."
While it is true, your correspondent obviously does not lose that assurance
after a conversation.
"Deniable authentication" is IMO contradictory. A better term might be "private
authentication", for example, meaning you privately authenticate to your correspondent. In any
case, we shouldn't simply name the property, we should describe what it provides.
--
Filipus Klutiero
http://www.philippecloutier.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
