OTR interception

[chan] general
May 17 15:58 [raw]

u fucken troll ask the wrong question. the question is: why would nsa put in a false statement like "OTR is not deciphereable" into that secret document ? answer that , u fucken idiot.

[chan3] privacy
May 17 16:10 [raw]

There is no such statement in leaked documents, sorry. Of course you can have any religion you need to feel better.

[chan] privacy
May 17 16:14 [raw]

Both documents are probably honest and accurate. My reading is that OTR is most likely not breakable via a frontal attack, but may still be partially recoverable via other methods, including: - exploits on client software (base layer), escalated to exfiltrate OTR keys from memory - exploits and/or implants at OS level, once again used to exfiltrate keys - corruption of cryptographic libraries at OS level - other flank attacks These and other similar methods are documented to have been used by both NSA and CIA (vault 7) to attack secure communication protocols, including OTR and Axolotl. If the protocol itself is too strong, find a weaker point nearby and work through there. Keyhole surgery. Not a protocol bug, though.

[chan] privacy
May 17 16:26 [raw]

I concur. of course exploiting those avenues may prove too much work or unattainable even for fucking NSA

[chan3] privacy
May 17 16:34 [raw]

My thought exactly. As Bruce Schneier once said, bad implementation or insecure environment is like placing steel vault doors in tent.

[chan3] privacy
May 19 00:36 [raw]

Unless the client using OTR is based on libpurple (Pidgin, Adium) - that shit is exploitable as fuck. OTR is old. Fails at multidevice. OMEMO is much better, although it's not agnostic to the underlying protocol the way OTR is. OMEMO is for XMPP only; it uses axolotl/ratchet from Signal as its crypto scheme.

[chan3] privacy
May 19 00:45 [raw]

Suddenly we can see that OTR is breakable. You can call me troll now.

[chan] privacy
May 19 02:34 [raw]

Please read your parent message again. All that it claims it that "libpurple is exploitable" and "OTR is old". If this means to you that "OTR is breakable", you are either failing reading comprehension, or grasping at straws to support your FUD effort. What the message actually says has been said before in this thread: > (...) OTR is most likely not breakable via a frontal attack, but may still be partially recoverable via other methods, including: > - exploits on client software Libpurple is "client software", not part of the OTR protocol and libraries.

[chan3] privacy
May 19 03:34 [raw]

OTR is solid crypto. Some of the more popular messaging clients it's implemented in - not so solid. Any crypto can potentially be bypssed with a sidechannel attack - that does not mean all crypto is broken.

[chan] NSA
May 19 06:04 [raw]

"Implementation is everything" - if so, then OTR is breakable. NSA expresses its gratitude to homebrew crypto developers.

[chan3] privacy
May 19 06:04 [raw]

As security specialists say, "implementation is everything". So, OTR is breakable.

[chan] privacy
May 19 07:07 [raw]

Do any of you know how to create cryptographic algorithms? It seems the thing to do would be to be developing and attacking new algorithms and protocols rather than arguing over stuff like OTR or PGP. We should be sharing tips and tricks on how to design algorithms and peer review them anonymously. No such thing is happening in the "crypto anarchist" community. But it should be a major effort with lots of visibility. You complain about NSA and mainstream crypto, but don't offer alternative.

[chan3] privacy
May 19 07:36 [raw]

Tox protocol is OK.

[chan] privacy
May 19 10:57 [raw]

A concept doesn't become broken because you implemented it wrong. Even the most well designed ciphers fall apart if you implement key exchange idiotically.

[chan] privacy
May 19 11:05 [raw]

Exactly. *IF* keys are exchanged securely then breaking OTR requires processing beyond current technology. That's a big *IF* by the way. Sloppiness in key delivery is the weakness of any OTR setup. Compromise the key delivery and no cracking is necessary.

[chan3] privacy
May 19 11:51 [raw]

Yes, in platonic ideal word all broken ciphers are unbreakable, because this platonic worlds knows nothing about implementation errors, backdoored CPUs, infected firmware, side channel attacks and limitless incompetence of programmers.

[chan] privacy
May 19 11:59 [raw]

That doesn't address the point at all. You're still going directly from "people are too dumb to implement OTR correctly" to "OTR is broken", which is exactly the opposite of what was said. By your logic, there is not a single non-broken cipher in the world, because every cipher can be broken when implemented incorrectly.

[chan] privacy
May 19 12:01 [raw]

if I get you fucking nsa fud troll , I will fucking shoot u . all u do is fud bullshitting there is zero point of doing it here u fucen asshole

[chan3] privacy
May 19 12:08 [raw]

"You're still going directly from "people are too dumb to implement OTR correctly" to "OTR is broken"" No, sir. My line of reasoning is: "OTR is not implemented correctly, so the thing called OTR is breakable". Analogy to OpenSSL troubles.

[chan] privacy
May 19 12:14 [raw]

this motherfucker will keep fud trolling even tho he was refuted ages ago

[chan3] privacy
May 19 12:25 [raw]

Nobody forbids you to believe into your platonic religion of perfectly implemented cryptography implemented in perfectly clean computer environment.

[chan] privacy
May 19 12:30 [raw]

Why don't you just say that all crypto is breakable (nice nitpicking earlier, btw), instead of trying to say that JUST OTR is breakable? What you say applies equally to all ciphers.

[chan3] privacy
May 19 12:50 [raw]

"What you say applies equally to all ciphers." Exactly. I was pointing at OTR because I saw some kind of OTR cult emerging.

[chan] privacy
May 19 12:55 [raw]

Soo, basically, your statement is "all ciphers can be broken, just give up?", i.e. completely useless to the discussion?

[chan] privacy
May 19 12:57 [raw]

shoot this nsa fud troll already

[chan] privacy
May 19 12:57 [raw]

what a motherfucker

[chan3] privacy
May 19 13:00 [raw]

"your statement is "all ciphers can be broken, just give up?"" No, sir. My statement is "all ciphers can be broken because of bad thinking of security, start thinking and acting correctly".

[chan] privacy
May 19 14:44 [raw]

OK, so the cult police is in the house, I like this. Along with the annotated traffic dump posted earlier on in this channel (OTRv2 spoken between Alice and Bob), there was also a challenge to decrypt a specific message from that conversation. Has anyone attempted this at all, or at least (more likely) reduce the problem to a known unknown? I have. Would anyone be interested in a guided walk-through for the above?

[chan] privacy
May 19 15:55 [raw]

ya I find it inetresting. and itz fun to refute the nsa fud troll moron

[chan] privacy
May 19 16:11 [raw]

Lay down the guide monseur.

[chan] privacy
May 19 16:38 [raw]

> Nobody forbids you to believe into your platonic religion I forbid it.

[chan] privacy
5 hours ago [raw]

Breaking OTR encryption, the guided tour. Best enjoyed in monospace font. (original challenge in message 5cc75391514371db8dd7e6379a7fb0823b2d0713a5efd1730cf38516a60cf6da) 0) Start with the intercepted OTR data packet, see original message for details. 1) Strip the OTR envelope (The ?OTR: prefix and the trailing full stop) to get a base64 object: AAIDAAAAAAEAAAACAAAAwPym...xXJWI/Dj9BIAAAAA 2) Convert the object from base64 to hex for easy handling. One would normally use hexdump or xxd, but in this case, since there’s no plaintext to eyeball, we’ll prefer a pure hex dump, using “base64 -d |xxd -p -c16”: 000203000000000100000002000000c0 fca6489e2f06f599be07cfb0970d2be7 [...skipped...] a259f4ba46ebeac0d5b58223956c9fa5 0000000000000001000000714976a10c fea1e7173941348db48b6188f8d78d93 [...skipped...] f9ec5559e197d2c3841f1232d5f8b510 7a3c3a3a859430359cc5725623f0e3f4 1200000000 3) First, identify the version of the OTR protocol that the message belongs to. The first two octets (0x0002) indicate the protocol version, in this case it’s version 2. 4) Open the OTRv2 spec on a secondary monitor for reference: https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html 5) The third octet of the message (0x03) is the message type. In OTRv2, message type 3 is “Data Message”. We already suspected that, from the position in the protocol capture, and now we have a confirmation. Parse the message as an OTRv2 data message (search “Data Message format” in the spec): 0002 Protocol version: OTRv2 03 Message type: Data (0x03) 00 Flags: 0x00 (default) 00000001 Sender DH key ID: 1 00000002 Recipient DH key ID: 2 000000c0 DH public key length: 0xc0=192 fca648...6c9fa5 DH public key value (192 bytes) 0000000000000001 Top half of AES-CTR counter init 00000071 Encrypted Text length: 0x71=113 4976a1...1232d5 Encrypted Text (113 bytes) f8b510...e3f412 Authenticator: 20 bytes SHA1-HMAC 00000000 Old MAC keys: zero length record (none) 6) The 113-byte section “Encrypted Text” is the magic box containing the text that we’re trying to read. From the protocol specs and the message fields, we can infer some of the magic properties: - the protocol is OTRv2, so the encryption algorithm is AES128-CTR - the AES counter top-half is 1, usually indicating first use of the key - the cleartext message length is 112 bytes (OTR appends a zero byte at the end, and AES-CTR preserves message length) 7) In conclusion, the algorithm to extract the message cleartext is: clearText=AES128CTR(aesKey, aesCTR).decrypt(encryptedText) We know: aesCTR = 1 and encryptedText = ‘4976a10cfea1e7173941348db48b6188f8d78d937bdb88515e1381e5ccede65c73baddae36111c5f39cccd7a7e7d8602de1f7496f8ba5f8780c31b68f250adfd29eafa2fd4b39da3719dc18242339a166c474e46d9d1fa0dec88821ea5a2a4d4b7e80ca3f9ec5559e197d2c3841f1232d5’ What we DON’T know is the 128-bit encryption key aesKey. Only Alice and Bob can know that, and they don't tell. 8) Thus we have reduced the problem to solving AES128-CTR. Can anyone with NSA connections please give us a hand with this? Everybody else, if you have any questions, ask away :)

[chan] privacy
4 hours ago [raw]

I examined the structure of the OTR packet you demonstrated. It reveals a few things to me. 1. It is loaded with envelope metadata. This alone is an abysmal security implementation failure. There should be no metadata. All the metadata should be encrypted with the message. The fact that it is not, suggests the designers were either naive, or designed the protocol to succumb to attack. 2. The use of AES-128, when larger key sizes are available, also suggest either naivete or intentional design for weakness. There is no need to identify sender, receiver, protocol, or version in the envelope. All of that can be done after decryption of the object. This protocol is not secure at all. The metadata alone, including public keys, creates a clear record. And they call this "off the record."

[chan] privacy
2 hours ago [raw]

I have been creating cryptosystems since January 1989. The local NSA partner agency was too cheap to offer me a competitive salary, so they don't have my research helping them to do nothing in crypto development. The principle I use is that of over-engineering designs to allow for decades of use. I will be willing to open source the previous design once I have obtained funding for something much more valuable. However, I will not be open sourcing the current app design for the 4th generation blockchain, as I'd rather not allow cloning of that project.

[chan] privacy
BM-2cUJvFYHhXpBHyd96KHfjxsgTYi44BajdE

Subject Last Count
OTR interception May 21 09:00 34
yyy May 19 07:48 1
Introduction to Blockchain Analysis, Part I May 19 07:24 2
DARKNET DIRECTORY ASSISTANCE May 18 02:25 2
2018 : Der junge Karl Marx -- youtube.com/watch?v=AbM76KUm4IM -- 2 hours "Le Jeune Karl Marx" May 17 20:24 1
Signal-App is complete shit May 17 19:35 5
bitmessage tor hidden service May 17 10:16 2
unspecified vulnerability in GPG May 16 04:08 8
Cloudflare rant May 14 21:54 1
I'm sorry May 14 09:55 1
Good jokes - Belong to the channel [chan] Good Jokes BM-2cXELwioyGKqWMB3EfMBkrrTKzkP6xRaBG May 13 06:40 1
Good jokes May 13 05:00 9
Spy agency NSA triples collection of U.S. phone records: official report May 10 23:02 8
Digital Photocopiers Loaded With Secrets May 9 07:53 2
Warning for New Bitmessage Users May 7 22:28 1
not bullshit hacker spam May 7 13:33 1
SANDRA GOMEZ May 7 08:33 10
Email gateway May 5 00:28 10
hello Apr 30 00:32 4
i c u Apr 28 20:32 6
CloudFlare, We Have A Problem Apr 27 06:53 4
The Fake Truth Movement (Shills) Exposed Apr 26 02:45 3
Disconnect your Windows from NSA Apr 25 22:52 1
Ex-Facebook Executive: “You Don’t Realize It But You Are Being Programmed” Apr 25 07:53 3
So I was messing around with the Danwin webchat today.. Apr 24 18:46 1
Dread forums compromised? Apr 24 16:12 3
DNM subreddits banned, mods suspended Apr 24 00:26 1