kaeporan

> You should have just conceded the point (it turned out later in the thread that you were wrong to have brought it up). Instead, you relentlessly personalized it. Now you're unhappy with how that went for you. Maybe this can be a learning experience.

My initial issue remains valid, and anyone who reads through the thread can see that you repeatedly attempted to change the focus to personalize this issue towards me. It's like I'm not allowed to offer any feedback, no matter how polite, constructive or valid, while you're around. Your doublethink is egregious.

Since you've asked me not to share contents of private emails, I won't. But your insistence on assuming bad faith on my part and rudely rejecting any conflict resolution from my end is deplorable, and you should be ashamed of how baselessly aggressive you have been towards me. You consistently spin everything I say and respond to my attempts to be constructive by encouraging groupthink against what I'm trying to say using irrational fodder.

You've ignored all my attempts to make discussion with you constructive. You are nothing but a great big bully and you should feel shame for your behaviour.

Every time I comment about anything on HN, and every time I am personally mentioned or my work is mentioned, you dutifully pop up to do your work. It's disgusting. You have a problem with me and anyone who cares to look into this can deduce the same.

I am not threatened by technical criticism, but you simply go so above and beyond reasonable discourse thanks to your irrational, mentally unfounded conviction that everything I ever do or write is necessarily either the result of incompetence or bad faith. Between me and you, it seems you never find the room for nuance and human respect!

That's my final say regarding you. Your technical knowledge is amazing and I've learned a lot from you. But you make HN a terrible place with your personality.

I'll make sure to answer any other comments so long as I have something to contribute.

I need to investigate this properly before I offer you an educated answer with details.

I hope I'm not mistaken, but my understanding is that you can have the same message C that would decrypt with K1 to the plaintext "Hello world" but with K2 to another plaintext of your choice ("Jello Warld" or whatever.)

Sorry, Thomas, but after you repeatedly replied to my private requests for conflict resolution with threats and abusive remarks, I refuse to interact with you entirely, publicly or privately. Those curious as to why I'm saying this should read Ptacek's other comments on this thread for a primer.

Zed Shaw was right: http://zedshaw.com/essays/thomas_ptacek_should_apologize.htm...

The attacker could send different Ks to each user so that K decrypts C to a different plaintext.

I don't think it would be trivial (it's likely possible to some degree, but authentication and integrity checks might make it slightly more difficult), but the issue with this protocol is that you don't even need server control — any client with TextSecure installed can do this.

Note: I don't mean to disparage TextSecure by saying this. By all means, TextSecure is a kickass app and you should use it. I'm just trying to point out something that could be fixed in a future update.

I endorse continuous transcript consistency, but believe that TextSecure currently does not allow its users to benefit from it and that this should be resolved. I think mpOTR is irrelevant to this discussion. I hope that's clear!

Thanks for laying out your thought process, it's very helpful.

> I pointed out that the protocol Cryptocat builds that UI on is so bad that you conceded downthread that you're building a new protocol --- you made that concession in direct response to my point about mpOTR's inferior transcript consistency.

This is the problem. You're assuming that my mention of mpCat was a concession made in "direct response" to your point about mpOTR, whereas it's actually brought up as a tangent. The reason we're building a new protocol is to be able to subject it to formal security proofs, as mentioned prior. It doesn't have to do with the existing protocol being "bad" or not or its current integration into the UI.

Regarding my other implied statements, I think it would be better to stick to claims I am explicitly making instead of assuming implications on my part. That being said, I apologize and will try to be more clear in my future comments in order to avoid assumptions.

I'm also not sure why you keep bringing up mpOTR. As I mentioned in my other post that you refer to, we're not using it anywhere nor do we plan to. We're building a modified version which is far less bulky, etc.

It really seems like you wrote this comment not to add anything to the conversation, but simply to discourage me from commenting. I really don't understand. I'm trying to be constructive here and I wish you'd join me. Your comment right now just flails around for abrasive things to put together into a statement that is completely incoherent and off-topic.

UI is absolutely a very difficult part of the problem, and here we see an example outlining this. Even a capable protocol still has problems if the UI fails to translate the capabilities into benefits and security increases for users. I speak from experience: Cryptocat has had some serious issues that were due simply to incomplete UI, the most recent of which was related to authentication.

Also, the reason for us moving to a new protocol has more to do with formal security proofs than being able to adopt new properties.

My original comment was simply to point out a current problem in this protocol design. There are some ways one can deploy to make it more difficult for Alice to send different messages to Bob and Carol without being detected, and they are deployed in Cryptocat (you're welcome to peruse the codebase and documentation.)

Just as a note, I'm sincerely discouraged from attempting to have an informative discussion with you by the fact that you keep assuming bad faith on my part, and generally responding in a needlessly rude and aggressive fashion. Consider that your general approach in this particular discussion might be why information security has a bad name as a poisonous field. If I don't reply to parts of your post, consider that it is because they are phrased in a way that assumes and implies a complete understanding, wrapped in aggression and the assumption of bad faith. I'm not here for that kind of discussion.

Thanks for agreeing to turn the discussion in a more constructive direction, Thomas.

I agree that mpOTR is a dead end. The initial paper by Goldberg et al describes a protocol that is bulky and largely undefined. I should mention that for those reasons, Cryptocat's group chat effort has been relabelled to "mpCat" instead of "mpOTR" — we're moving on to creating a protocol suitable for synchronous use-cases specifically (since TextSecure already has the asynchronous use-case figured out) without shouldering the bulkiness and obsolete nature delineated in mpOTR's original description. One of the things that is actually addressed better is transcript consistency: in mpCat, it will function on a level of reliability that is in fact continuous and not just occurs once per entire conversation.

We recently concluded mpCat's first review summit, and were very lucky to have the feedback of experts such as Trevor Perrin, Joseph Bonneau and Ximin Luo. We also invited members from TextSecure's team in order to help us understand the use-cases scenarios they have experience in. For what it's worth, the TextSecure members that were invited were seen as open source peers, and not as "competitors" as you put it. I should mention that TextSecure's research frequently came up while working on mpCat, and that they are contributing more to this field than most other projects. That's why I say they are inspiring.

I'm sorry, but I don't think your approach to this discussion is constructive. I hope TextSecure developers address my initial concern, and that's all for me.

I think TextSecure is an excellent and inspiring project. All I'm trying to do is identify an area of concern for me. I'm not sure why you're attacking me personally here. I think my initial point of concern stands and I hope the TextSecure developers will work on addressing it.

And yes — I believe my work on Cryptocat does grant me some helpful perspective on the kind of issues faced in group chat. I'm more than happy try my best to offer some insight to other great open source projects. If I wanted to sneakily hide that I work on another encrypted messaging project (why would I? Open source projects discuss issues with one another all the time) it would have been simple for me to create another username.

I'm quite certain that the current TextSecure chat allows my proposed scenario with Alice, Bob and Carol to go through without issue. This is the main problem here. So while transcript consistency is discussed in the blog post, it remains the case that Alice can send a different message to Bob and Carol without being detected.

Yes, per your quote, transcript consistency is discussed. But the discussion simply outlines problems with implementing it in their mobile use case — to my understanding the current version being offered to users doesn't have strong transcript consistency.

The fact that transcript consistency is waved aside, despite being an essential property of a messaging protocol especially in a group context, is problematic, from my perspective.

Consider a group chat between Alice, Bob, and Carol. With this protocol, Alice can selectively send different messages to Bob and Carol with both of them thinking they got the same message.

For example, Alice can tell Bob "The funds were transferred, thanks!" and tell Carol "Bob is stealing money." — and the protocol will ascribe integrity to the messages for both participants and label them as the same message.

That said, I strongly respect Open Whisper Systems. They usually release very well thought-out material. Perhaps they should have paid more attention though to this particular issue.

I disagree; I don't think your summary is accurate. This is an audit of a pre-release prototype. All the bugs were fixed before release, and our blog post at https://blog.crypto.cat/2014/04/recent-audits-and-coming-imp... does not discuss mere band-aids. It discusses, at length, real solutions to complex problems that many encryption apps face. It resolves pitfalls that even companies like Apple commit on a much wider scale and on a much more dangerous level.

For example. We didn't simply "re-use fixed IVs". We know not to do that. The resulting bug was the series of a much more complicated and hard to spot issue with the re-keying mechanism. Understand you might not have the full picture here.

Simply put, I refuse the assertion that Cryptocat's team has not dealt with its software development in a competent, professional, responsible and honest fashion.

I want to discuss this further with you. I want to convince you of my point of view. Please email me at [email protected] so I can have the opportunity to discuss with you and hopefully convince that your perspective isn't exactly right on this.

To be clear, I'm not trying to cast aspersions. As I've already stated, TextSecure is a great project that I strongly recommend.

I'm trying to have a serious discussion regarding transparency of audits. I feel your reaction is overly aggressive and not genuinely constructive.

Why isn't Moxie replying? Publishing an audit, with or without vulnerabilities, surely is beneficial to TextSecure. I don't understand their reticence to publish audits. We know OTF has commissioned at least two audits for them, but not a word has been heard about them.

In fact, OTF has actually complained about their projects choosing not to publish audits: https://www.opentechfund.org/article/bringing-openness-secur...

I was the person who wrote to OTF asking them to fund our audit. I have no idea if they require it — I'm always the one to initiate the process.

It's important to note that this audit was commissioned to evaluate a prototype build before release. It was expected to find bugs, and all bugs were fixed before release. I believe I take my job very seriously when I commission such audits on a bi-annual basis and transparently discuss the results. Independent individuals who find bugs (such as "Decryptocat") are also listened to and rewarded for their effort. I believe that I and my team have been competent, honest and hard-working. If all encryption projects were as transparent as us, you would realize that this kind of issues happens everywhere.

Please make sure to read our blog post and Github discussions to see the kind of open discussion we're hoping to lead so that our software can benefit.

That being said, I suppose comments like yours are why I've been having recurring suicidal thoughts for the past two years. I don't know what else to say at this point.

Hmm. Cryptocat was actually the first ever OTF project. I believe they've always asked for the publication of audits.

What I'm curious about is, why don't other projects such as TextSecure publish their audits as well? I'd certainly appreciate Moxie answering this question.

The OTF blog post certainly makes good points for this to happen. I also personally believe that this reticence to publish audits is damaging to the opportunity for the honest evaluation of encryption software and the establishment of a realistic perception of encryption software. It also misleads users.

Since I am familiar with the process, I know for a fact that OTF asks every project whether they'd like to publish their audits, including TextSecure.

That being said, what is stopping you from publishing the audits today?

Cryptocat has always provided ample warnings that no software can ever be trusted with your life. These warnings appear every time you launch Cryptocat, on the website and in various guides and blog posts.

We submitted a pre-emptive build just to obtain approval from Apple. We were going to wait to update it with the audited build before actually releasing it (Apple lets you schedule releases in advance.) In retrospect, it was lucky we got Apple's rejection early on, so we were able to deal with it better.

iSEC also audited TextSecure, but TextSecure chose not to publish the audit.

I agree! TextSecure is an excellent project. We're actually very lucky to be able to bring in Trevor Perrin this month to contribute to Cryptocat.