Bug#766936: [pkg-otr-team] Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
On 2014-10-29 05:49, Ian Goldberg wrote: On Tue, Oct 28, 2014 at 08:56:07PM -0400, Filipus Klutiero wrote: 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. No, that's not quite right; OTR sends the authentication (MAC) key *in the clear* so that anyone capturing the traffic on the wire can subsequently modify transcripts however they like. That's also what I was saying. It is not encrypted, but it has no effect except in cases where the communication is captured. -- 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
Bug#766936: [pkg-otr-team] Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
On Tue, Oct 28, 2014 at 08:56:07PM -0400, Filipus Klutiero wrote: 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. No, that's not quite right; OTR sends the authentication (MAC) key *in the clear* so that anyone capturing the traffic on the wire can subsequently modify transcripts however they like. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766936: [pkg-otr-team] Bug#766936: Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
Hi, Ximin Luo wrote (28 Oct 2014 01:11:27 GMT) : Both of you are right in some degree. Deniability is indeed a secondary property of the underlying authentication system (note: *not* encryption system as Harlan said). It makes no sense without authentication. However, I'm neutral as to merging the two points. With OTR, users get deniability, which is an important feature for them. It seems to me that most users don't care at all that deniability is a secondary property of the underlying authentication system. If we have to make a choice, I'd rather focus on what is important from the user PoV. It may be that we don't have to make a choice, see below. A related point is that forward secrecy is a secondary property of the underlying encryption system. It makes no sense without encryption (i.e. confidentiality). Personally, I like to introduce these concepts as forward-secure confidentiality and deniable authentication. I suspect that with all this info in hand, someone who cares strongly about this could come up with a phrasing that: * structurally, focuses on users' needs, and features they can see * manages to sneak in the correct terminology that Ximin is proposing, somehow Any taker? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766936: [pkg-otr-team] Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
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
Bug#766936: [pkg-otr-team] Bug#766936: Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
On 27/10/14 03: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. In that context, I think it might be deserving of being listed as its own feature. Both of you are right in some degree. Deniability is indeed a secondary property of the underlying authentication system (note: *not* encryption system as Harlan said). It makes no sense without authentication. However, I'm neutral as to merging the two points. A related point is that forward secrecy is a secondary property of the underlying encryption system. It makes no sense without encryption (i.e. confidentiality). Personally, I like to introduce these concepts as forward-secure confidentiality and deniable authentication. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
Package: libotr5 Version: 4.1.0-1 Severity: minor The extended description contains: OTR allows you to have private conversations over IM by providing: [...] - Authentication - You are assured the correspondent is who you think it is. - Deniability - The messages you send do _not_ have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, _during_ a conversation, your correspondent is assured the messages they see are authentic and unmodified. So-called deniability is not a feature per se, unless authentication is taken for granted, which is clearly not the case here. Rather than advertising 2 independant items, these could be merged in a Deniable authentication item which would contain both sublists. 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. -- 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
Bug#766936: [pkg-otr-team] Bug#766936: [libotr5] Extended description: Deniability is not a feature per se
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. In that context, I think it might be deserving of being listed as its own feature. 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. -- Harlan Lieberman-Berg ~hlieberman signature.asc Description: This is a digitally signed message part
