full-disclosure - Re: Skype chat encryption with OTR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8eb59e340806190655q5b0b1062v24317c33f3f85618@mail.gmail.com>
Date: Thu, 19 Jun 2008 08:55:01 -0500
From: JM <ubahmapk@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Skype chat encryption with OTR

On Thu, Jun 19, 2008 at 01:28, Tonnerre Lombard
<tonnerre.lombard@...roup.ch> wrote:
> Salut, rawket,
>
> On Thu, 19 Jun 2008 13:00:49 +1000, rawket wrote:
>> /There is no denying that an OTR Conversation has been encrypted..
>> Its because the private keys change ultra-frequently, and the keys
>> are short lived that it provides the 'plausible deniability'
>
> Not exactly. The plausible deniability is due to the fact that the
> signature is executed using a symmetric key known to both parties, so
> that either party (but noone else) could have sent the message.
>
>                                Tonnerre
>

Actually, the shared keys are *published* once they're discarded to
improve plausible deniability.  That lets anyone forge an *old*
message, but ensures you wont' accept a forged message during the
course of the conversation.

>>From http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html

Revealing MAC keys

Whenever you are about to forget either one of your old D-H key pairs,
or one of your correspondent's old D-H public keys, take all of the
receiving MAC keys that were generated by that key (note that there
are up to two: the receiving MAC keys produced by the pairings of that
key with each of two of the other side's keys; but note that you only
need to take MAC keys that were actually used to verify a MAC on a
message), and put them (as a set of concatenated 20-byte values) into
the "Old MAC keys to be revealed" section of the next Data Message you
send. This in done to allow the forgeability of OTR transcripts: once
the MAC keys are revealed, anyone can modify an OTR message and still
have it appear valid. But since we don't reveal the MAC keys until
their corresponding pubkeys are being discarded, there is no danger of
accepting a message as valid which uses a MAC key which has already
been revealed.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/