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.
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.
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.
May 17 16:26 [raw]
I concur. of course exploiting those avenues may prove too much work or unattainable even for fucking NSA
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.
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.
May 19 00:45 [raw]
Suddenly we can see that OTR is breakable. You can call me troll now.
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.
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.
May 19 06:04 [raw]
"Implementation is everything" - if so, then OTR is breakable. NSA expresses its gratitude to homebrew crypto developers.
May 19 06:04 [raw]
As security specialists say, "implementation is everything". So, OTR is breakable.
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.
May 19 07:36 [raw]
Tox protocol is OK.
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.
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.
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.
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.
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
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.
May 19 12:14 [raw]
this motherfucker will keep fud trolling even tho he was refuted ages ago
May 19 12:25 [raw]
Nobody forbids you to believe into your platonic religion of perfectly implemented cryptography implemented in perfectly clean computer environment.
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.
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.
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?
May 19 12:57 [raw]
shoot this nsa fud troll already
May 19 12:57 [raw]
what a motherfucker
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".
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?
May 19 15:55 [raw]
ya I find it inetresting. and itz fun to refute the nsa fud troll moron
May 19 16:11 [raw]
Lay down the guide monseur.
May 19 16:38 [raw]
> Nobody forbids you to believe into your platonic religion I forbid it.
May 21 05:12 [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 :)
May 21 06:20 [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."
May 21 09:00 [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.
May 21 12:55 [raw]
You raise two good points. 1) By design OTR is not a stand-alone communication protocol; it is a content encrypting overlay for existing protocols, most of which operate on a user account / session basis: IRC, XMPP, Office, Facebook etc. From this perspective, OTR does not disclose any addiitional information beyond what is unfortunately already disclosed at the base protocol level (see NSA intercepts). What OTR does is protect the content. Also, none of the OTR metadata is identifying, as the keys are generated individually for each message and not linkable across messages. You may be applying a common prejudgment "metadata is vulnerability" to the wrong type of metadata. :) 2) It's true that the protocols and key sizes are a bit outdated (the whitepaper was first released 14 years ago), this is being addressed in the version 4 of the protocol, currently in development: https://github.com/otrv4/otrv4/blob/master/otrv4.md Note, however, that neither DH group 5, nor AES-128-CTR are computationally breakable with current technology; they're just considered less future-proof than they were believed to be 14 years ago. Anyway, it's an interesting discussion, but I didn't hear the objection that I was hoping for. Anyone else want to try?
May 21 19:18 [raw]
> 'I will be willing to open source the previous design once I have obtained funding for something much more valuable.' I share this sentiment. I want to open source my designs, but nobody who benefits from it will give me a thin dime. After I recoup my investment I will consider releasing open source libraries. It is sad that companies who might make millions or save millions using your design want it for free and don't want to pay. That is what Gnu/OSS is really all about--getting a million programmers to write free software for the government and big business. All the hype about freedom is bullshit. It's about the freedom of the big firms to use your stuff without paying you a cent.
May 21 19:20 [raw]
> Anyway, it's an interesting discussion, but I didn't hear the objection that I was hoping for. delve, delve
May 21 19:30 [raw]
Please read GNU license. More than once. With comprehension.
May 22 04:50 [raw]
I was thinking SHA1 would be a pretty juicy elephant-in-the-room, no? :)
May 22 06:27 [raw]
More exactly, which cryptocurrencies are based on SHA-x ? :-P
May 22 06:50 [raw]
juicy elephants make better barbecue good call i got sauce
May 22 06:55 [raw]
The previous design is reliable and well-spread over the last decade, however it is still considered competitive with current cryptography research. What I would rather profit from is how my research works as a new type of blockchain, however no company is willing to pay for the research at a fair rate, and they would rather just acquire buzzwords they don't understand for their ICO whitepaper. I've heard of lead blockchain programmers who barely know how to code, techical advisors to blockchain companies who don't know the first thing about cryptography or databases, even marketing types who want a technical review to be a glowing recommendation for a piece of crap. The there is all the idiots praising solidity as if it isn't a buggy piece of crap favoured by the smart contract crowd. Anyway, I should probably head to the toilet if I want to give a crap. :-)
May 22 06:56 [raw]
To heck with that, I choose what I do with my work.
May 22 07:14 [raw]
> crap favoured by the smart contract crowd. Smart contracts are an even bigger hasbarabot scam than ICOs.
May 22 07:36 [raw]
> no company is willing to pay for the research at a fair rate, and they would rather just acquire buzzwords Those having money, believe they are entitled to more money at the expense of those who do all the work.
May 22 07:45 [raw]
Exactly. Would rather just raise money the traditional way for something worthwhile than be associated with the global scam market.
May 22 07:57 [raw]
Now they're calling it "the ICO market." There is no market. It's people taking your money for a fantasy.
May 22 17:30 [raw]
But bashing it is so much more trolly fun. What do you expect to get from the hordes here?
May 23 01:33 [raw]
And you are not trolling us about leaving our hard work to go unrewarded ? Not everyone can afford to donate our efforts when we have little funds from other things.
May 29 11:28 [raw]
Public key shall exist outside the encryped data. data = [encrypted]+[pubK] What do you think about ricochet.im's protocol? Just curious.
May 29 12:16 [raw]
Guys, you're about 15 years behind the times. Welcome to 2003.
May 29 12:46 [raw]
Hey, it (OTR) keeps the NSA Utah facility ticking over with juicy decrypts.
May 29 14:23 [raw]
Jun 2 05:59 [raw]
Oh, I'm pretty sure it was Washington post 2013. Don't have the URL to hand, the printout is in my office. You should be able to find mention of "AES decrypt facility in Utah" on "the intercept" website.
|Tails:||Jul 18 22:02||5|
|BitText H67jQHynwu: privacy software||Jul 17 21:52||4|
|how to stay completely anonymous?||Jul 16 17:44||5|
|circus||Jul 16 17:15||5|
|BEAMSTART||Jul 16 17:12||1|
|BitText List||Jul 15 01:10||1|
|peter_surda_privkeys||Jul 13 21:26||1|
|Jacob Appelbaum: Wikileaks insider, military contractor, Tor developer||Jul 2 01:51||5|
|Tor Usage Paints a Target on Your Head||Jul 1 13:56||13|
|DARKNET DIRECTORY ASSISTANCE||Jun 30 22:29||1|
|BitText LIST||Jun 26 06:23||1|
|Linux firewall QA||Jun 26 06:20||1|
|KASPERSKY INTERNET SECURITY 2013-2019 - 366 DAYS FOR (WINDOWS, MAC, ANDROID) ACTIVATION CODES SALE.||Jun 25 07:24||2|
|Why is Tor not enough for Deep Web Anonymity?||Jun 23 18:47||1|
|How to Legally Accept a Drug Package as Per Police and Prosecutors||Jun 23 18:47||1|
|Reminder||Jun 23 11:52||2|
|Hello||Jun 23 02:57||3|