For those who don't know, here was Thomas Ptacek recently joking about Nadim's penis: https://mobile.twitter.com/tqbf/status/705825790529662976
Here he is telling Nadim "go fuck yourself, forever": https://mobile.twitter.com/tqbf/status/705900243313758208
This is unprofessional. That kind of bullying is especially unacceptable coming from someone who has a lot of money and a pretty big audience, directed at someone who is young and just starting out.
I think Hacker News should be better than this.
I'm not sure how linking to twitter supports your comment that HN needs to improve. If he'd said that on HN he'd have been (I assume) banned. dang is constantly asking people not to be mean or dumb, or banning people for being mean.
dang is great. I just wish we had a bit less negativity.
--
Finally, a brief history for readers who dont know yet:
* Cryptocat v1 was a cat themed anonymous chat webapp with very broken homebrew encryption. It was basically Nadim's crypto learning project as far as I can tell when he was ~20 years old.
* Snowden allegedly used it at some point. Oops.
* Crypto experts reviewed it and found significant flaws. Tptacek wrote about how terrible it was, how JS crypto is Considered Harmful, how amateurs shouldn't write crypto because they could get someone killed, etc
* Cryptocat v2 a desktop chat app using Axolotl / Signal Protocol for e2e encryption. Nadim is a phd student now. It's a new and totally separate codebase.
tldr; there's no reason to assume that Cryptocat v2 sucks in the ways the original did. It may be totally sound.
(I have no involvement w the project and have not reviewed the code.)
No he wouldn't.
The knives are out for Signal. It's not hard to see that. Of the "independent" messaging schemes, Signal is probably the only one that has a chance of relevance 5 years from now. Everyone else is working on something that will be a checkbox feature for Apple, Google, Microsoft and Facebook in less time than that.
I'm happy about that. Clearly, not everyone else is.
Which is exactly why I, even though I don't care much for drama (infosec drama especially), find myself "complaining" about Signal from time to time. Because we are going to have to live with it. If I could go back and "complain" about PGP, before that became the preferred "just use" argument, I would.
What did he do? Does he know what he did? Do we ever get to find out? The people want answers.
Nadim has enough information to know what that hash corresponds to. Maybe he'll tell you. I won't. Not until I'm ready.
I don't think it should. I think us pretending that we are some group of regal statesmen is a bunch of pretentious bullshit.
Being civil is preferable, but not if it means being fake.
People aren't any less "mean" on HN, they're just good at bullying in more subtle ways, and we are all worse off for it.
I don't understand this. Everything is fake to some degree. Being civil is a good thing.
And indeed, with a quick browse through the Wire [0] and OWS [1] repositories I just can't find any kind of commonalities at all. Not in the structure, not in the comments, not in naming, not in the data structures, etc. Am I missing something, is there anything at all in the code itself that suggests the two codebases are related in any way at all? Or is the "GPL's OWS code" you refer to something else entirely?
[0] https://github.com/wireapp/proteus/tree/develop/src/intern
[1] https://github.com/WhisperSystems/libsignal-protocol-java/tr...
// Based on libsignal-protocol-java by Open Whisper Systems
If there's GPL violation and code was copied, there should be some traces of that. Is it truly so unreasonable to ask what those traces were?
Though I did just Google it, and throwing an extortion claim on top sounds... well, like a big mess.
Given that I'm mentioned by name (and tied to a bunch of exaggerated claims), I'd like to clarify a few points.
1. I never claimed that a GPL violation was impossible because of different programming languages. I merely questioned whether this was the case with Wire's Rust codebase [0], given that its data structures, namespacing etc. are substantially different from the OWS Java code [1]. To me, different code organization + different implementation style + different programming language don't exactly amount to a line-by-line conversion from Java to Rust as OWS seems to be claiming.
2. Cryptocat does not compete with Signal: it's a desktop XMPP client that focuses on synchronous messaging (that I write in my free time and with no funding or business plan, to boot), and does not at all target the mobile space. I was very happy to adopt a variant of Signal Protocol into Cryptocat and consider Signal's contributions to the field of secure messaging to be highly valuable. I'm not sure why tptacek brings up Cryptocat (completely unrelated to this discussion) but by all means, don't avoid it! The recent rewrite is pretty good, actually.
Overall, this situation just struck me as very ugly. Moxie seemed at some point to be reticent to allow fully independent implementations of the protocol, and Wire's lawsuit was pretty aggressive. Both parties locked in a catfight and then (apparently?) realized their approaches were counterproductive and gave it up.
The best resolution here, in my view, would have been for Moxie to publish a public-domain reference specification document of Signal Protocol that's independent of the code, and for Wire to be allowed to write a Rust implementation of it without any party causing drama.
[0] https://github.com/wireapp/proteus
[1] https://github.com/WhisperSystems/libsignal-protocol-java
Your messages on Twitter are right there for everyone to read.
Here's a helpful starting point:
https://twitter.com/kaepora/status/730165751240364033
The preceding link where you referred, unbidden, to Moxie's last post about their take on federation for their own implementation of Signal as a "dishonest rant" is left as an exercise for the reader.
Thank you
* AES-CTR counter-reuse (2012)
* Biased Fortuna CSPRNG implementation [1] (2013)
To be sure, Cryptocat's substandard reputation was well-deserved; but all the same, I think that every vulnerability that did pop up was addressed responsibly and with full disclosure.
Since then, there has been a major rewrite that I am conversely quite happy with.
[0] https://tobtu.com/decryptocat.php
[1] https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...
Good for his consulting rate, no doubt, but probably not good for society.
Steve was paid two separate bug bounties and invited to a Cryptocat hackathon in NYC. I also consider him a friend and never heard a complaint from him regarding the project's disclosure policies.
The bug that lasted 347 days was the confusion between a string and an array of integers. This made the ECC private keys ridiculously small because they passed a string of decimal digits into a function expecting an array of 17, 15 bit integers. Each character was considered an element in the array. So each of those "15 bit integers" were only the values 0 to 9 (3.32 bits). Also the least significant 3 bits are zeroed giving you a key space of 210^16 (2^54.15).*
When they fixed that bug the commit message was: "Fix private key format to match curve25518-donna. THIS BREAKS COMPATIBILITY WITH PREVIOUS CRYPTOCAT VERSIONS." Even though this does not break compatibility at all. I don't know if they knew what they fixed and just wanted to slide this under the radar or they legitimately believe that. Both are scary one is violating their principles "Cryptocat is developed under a principle of radical transparency" and the other is just incompetence. There is a blog post by them saying this is inaccurate. Apparently they have too many serious bugs to keep straight. That they don't know which one breaks compatibility. The other error in the change log for version 2.0.42 is a bug where the counter in AES-CTR is reused. This means the first 32 bytes of your messages are easy to decipher with no effort at all. Which breaks compatibility, but everywhere they mention compatibility they say key generation.
Here's one walkthrough of their broken PRNG: https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...
Decryptocat lists some of the other bugs: https://tobtu.com/decryptocat.php
The response - "bugs happen, we'll fix them" is okay for most other software, but probably not for cryptography. Especially not if you're marketing your software to people at risk of being murdered by their governments.
Here's a snippet from their blog, there are plenty of others:
> In working with young and middle-aged professionals in the Middle East region, we have discovered that desktop OTR clients suffer from serious usability issues which are sometimes further exacerbated due to language differences and lack of cultural integration (the technology was frequently described as foreign). In one case, an activist who was fully trained to use Pidgin-OTR neglected to do so citing usability difficulties, and as a direct consequence encountered a life-threatening situation at the hands of a national military in the Middle East and North Africa region.
They're the victims of being over hyped. There's some discussion to be had around how much they generated that hype. http://paranoia.dubfire.net/2012/07/tech-journalists-stop-hy...
The genesis of this claim comes from Wire having used GPL'd OWS code, apparently for the Signal protocol, without complying with the GPL. OWS demanded that Wire comply with the GPL.
Apparently, upon being told that they would be required to comply with the GPL, they inquired instead about dual-licensing. That's standard practice when a company adopts GPL code for their own product but doesn't want to comply with the GPL: they instead have to pay for a private license.
Instead of paying for a private license, Wire has apparently chosen to comply with the GPL instead, and withdrawn their complaint. I think that was the right choice.
The knives are definitely out for Signal now that its importance is being recognized by a wider audience. Complaints about Signal are, unsurprisingly, getting dumber and more venomous. For instance, last week, Nadim Kobeissi (the author of Cryptocat, a competing secure messaging system that I think you should avoid) was on Twitter talking about how impossible a GPL violation could have been given that Wire's Signal implementation is in Rust.