[messaging] Value of deniability

[Ximin Luo]

On 12/12/14 15:53, Daniel Kahn Gillmor wrote:
> On 12/12/2014 09:12 AM, Bruce Leidl wrote:
>> It seems rather unfair (maybe even hostile) to users to sell them on purported
>> 'secure' communication protocols which are in some ways inferior and actually
>> less secure than not using them because an obvious intuitive property of clear
>> text communication has been undermined in a way we can't even explain to them.
>>
>> If deniability was impossible or impractical to achieve then I guess
>> we'd have to
>> then figure out how to effectively warn users about how cryptography complicates
>> repudiation, but since we do know how to design for deniability then
>> we should do
>> that obviously.  Yes?
> 
> Yes, i think this is the most important takeaway from this conversation:
> 
>  * deniability doesn't give users anything they don't already have, and
> is certainly not some sort of silver bullet in any legal (or non-legal)
> situation.
> 
>  * non-repudiable cryptographic signatures (i.e. lack of deniability) is
> something whose consequences have been rarely tested in the courts, and
> could be actively (perhaps surprisingly) harmful to users of systems
> that they thought were secure.
> 
> So the argument for planning for deniability is not "check out this cool
> new feature", but "please don't make things any worse than they already
> are."
> 

Hear, hear. 

Can we all talk about something more productive now, please? There are lots more problems to be solved in group chat, and getting stuck on deniability hinders progress. AFAIK, everyone still actively working in this area no longer considers this topic to be an issue of contention.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141212/7e227c7d/attachment.sig>