[OTR-dev] Evidence of intelligence agency decryption of OTR chats

Nadim Kobeissi nadim at nadim.computer
Mon Dec 29 07:32:36 EST 2014


It really doesn't seem to me that the current disclosures allow for more than vague guesswork. It's very unlikely that the breaks are in something like AES-CTR. The only useful conclusion, probably, is that all relatively more fragile aspects of the software (user RNG, C implementation, underlying Pidgin/Adium client) could use more review. Which is something I'd say we knew already.

Sent from my BlackBerry

  Original Message  
From: Gregory Maxwell
Sent: Monday, December 29, 2014 6:34 AM
To: otr-dev at lists.cypherpunks.ca
Subject: Re: [OTR-dev] Evidence of intelligence agency decryption of OTR chats

On Mon, Dec 29, 2014 at 11:21 AM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Sun, Dec 28, 2014 at 11:40:02PM +0000, Gregory Maxwell wrote:
>> http://www.spiegel.de/media/media-35552.pdf
>>
>> >From http://www.spiegel.de/international/world/nsa-documents-attacks-on-vpn-ssl-tls-ssh-tor-a-1010525.html
>>
>> The fact that they appear to have decrypted some but not all messages
>> in a log suggests to me that this is not a host compromise, or an
>> MITM. But potentially an attack on 1024 bit DH or AES-CTR?
>
> OTR uses 1536-bit DH, not 1024-bit DH.
>
> It's possible the transcript on the second page of that PDF shows
> protocol messages (OTR Query, key exchange, etc.) messages. But I don't
> have a similar explanation for the ones after the undecryptable OTR
> messages on the first page.

I thought the same thing about the second page. The second page also
could have been "We should switch to OTR" "Okay".

The theory about intermittently bad RNGs in some clients sounds
interesting. It would be a reason why the capability to monitor might
blink in and out as the forward security ratchet turns.

A more robust implementation approach might be to chain like
new_PFS_key = H(prior ephemeral key including from past sessions ||
new randomness) so that if ever the PFS key is secure it's always
secure even if the local RNG is untrusthworthy.

It's annoying that the slow, intermittent disclosures by the media,
and voluntary redacting may well be leaving people at risk because
we're unable to extract many technically relevant details.
_______________________________________________
OTR-dev mailing list
OTR-dev at lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev


More information about the OTR-dev mailing list