Hacker News new | past | comments | ask | show | jobs | submit login

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption

https://twitter.com/lclarkmichalek/status/544882194456776705




This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you."

That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more depth in an email?" Even if you're dealing with a troll, this is still the best strategy.


I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing?

Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.


To put it simply, if @monadic were receptive to @lclarkmichalek's ideas, why did he end the conversation?

But let's look at the Tweet in question:

"@lclarkmichalek @weavenetwork please, if it is so simple and robust you are very welcome to contribute a patch."

1. He says "please", which in this case is sarcastic.

2. Then he says "if it is so simple," which is a dismissive way of saying "you think that it's simple, but you're wrong – it's actually very complicated."

3. And also "if it so so ... robust," which is a dismissive way of saying "you think that it's (more) robust, but you're wrong – it isn't."

4. And finally "you are very welcome to contribute a patch," which, first, does not need to be said as presumably anybody knows that they are welcome to submit a patch to an open source project, and second, basically amounts to "so, I'm going to make my problem your problem."

This case is different from a feature request from a user, where "feel free to do it yourself" is slightly less inappropriate. There, what is meant is "this feature is not important enough to warrant our endorsement or any allocation of resources, but if you were to take on the burden entirely yourself, we would consider it."

In this case, what is meant is something more like "we believe that your charge that there is a fundamental issue with our software is false and we are not interested in discussing until you have actually done the work for us," or in other words "fuck you."

I admit, "fuck you" is quite strong for the general case, but the tone of the Tweet warrants that translation.


I'm sorry but I find your interpretations of 1-4 completely uncharitable and unreasonable.


What you meant is clear to you. It's not clear to other people. You can chose to ignore them - maybe the people who misread the tweet are a small minority. Or you can chose to think about communication style and whether more people had the same "uncharitable" interpretation.

For what it's worth I lean more to the uncharitable reading of the tweet, although I'm not as firm about that reading as others appear to be.

Tweets for communication are hard so it's not particularly suprising when what you say and what you think you say doesn't match what other people think you said.


I don't; if anything, I personally find them too charitable and reasonable.

Just admit that you (if you're the one who wrote that response; it's not exactly clear who's who in this discussion...) were being a bit of a twit and move on. We all do it; I do it, the girl next door does it, my grandma even does it and she's the nicest person I know. There's no shame in being honest about it.


No, for example it is 100% uncharitable and unreasonble to assert that "please" is sarcastic. The truth is quite the opposite.


I think we'll have to agree to disagree on that one, then, though thanks for the clarification nonetheless.

Typically (at least in American English vernacular), "please" is very frequently used in a sarcastic manner (e.g. "You think you can jump from the top of that building and not get hurt? Bitch, please." or "Oh please, like you know the difference between a grape and a grapefruit."). While this sarcastic usage is usually accompanied by some other word prefixing it ("Oh please" or "Bitch please" or "Nigga please" or somesuch), it's not uncommon to see a lone "please" used in this sense as well, and the tweet in question very closely resembled that usage.


I'll have to stop saying please when in the US then ;-) But seriously, thanks for taking the time to explain your point of view. alexis.


> To put it simply, if @monadic were receptive to @lclarkmichalek's ideas, why did he end the conversation?

It was actually @lclarkmichalek who ended the conversation.


That does not appear to be the case to me :/


Also, agree with above post that you should use your own name as here I am awkwardly talking to you in the 3rd person.


"Fuck you" would have indeed been a more appropriate response to "how dare you try to implement crypto" FUD.

Crypto is hard, but it's no harder than a lot of other hard things. If you think someone's crypto is broken, you could point out why you think it's broken. I see no evidence that consigning crypto to a forbidden zone is going to improve real world security, and the old "mature" cruftpiles seem to manifest problems at least as often as newer systems designed with the benefit of hindsight. For example, any competent designer of a newer system would always authenticate before decrypting-- something that was not clearly understood when SSL was developed.


> Crypto is hard, but it's no harder than a lot of other hard things.

Crypto is a LOT harder than some other things.

3d graphics programmers don't have to worry about side channel attacks through timing disclosures through random numbers returned over an HTTP GET.

Physics simulations don't have to worry about tens to hundreds of millions of dollars of losses because Intel changed the L2 cache slightly in some revision of a processor and now it is possible to glean a couple bits of information about the entropy one uses.

Of all the projects I have worked on, maybe the C/C++ compiler had a set of worries close to what an encryption suite has.

You could toss me into almost any field of software engineering and after a few months I'd feel good. Some of them would have a longer ramp up time (order of months). Some of them might require me to go take a few online courses to learn the field (3D, physics sims, etc).

Encryption requires an entire life of devotion. New attacks are coming out all the time. There is so much financial incentive in the field that the competition is insanely fierce.

3D graphic techniques get pushed forward by publishers wanting the latest AAA game title.

Encryption gets pushed forward because they are trying to outrun either large international criminal organizations or entire governments.


You're right, though there are some things that are about as hard: compilers, language design, machine learning, databases with strong ACID guarantees, etc.

The problem I have with the "crypto should be a forbidden zone" line of reasoning is that the real world evidence shows that the old battle tested systems manifest flaws at least as often as competently designed newer systems do. Crypto, it turns out, is so hard that the probability of lurking issues with mature systems approaches or exceeds the probability of mistakes in new ones.

When I say competently designed, I mean a newer system that passes the sniff tests of experienced crypto engineers. An incomplete list: they're using a cipher that's been peer reviewed and is considered strong by modern standards, they're using that cipher correctly, they're authenticating before doing anything, they are using an IV (if needed), they are not sending anything secret in the clear, they're not branching on secret data, etc.

It's also important to refrain from criticizing people for claims they are not making. As far as I know, Weave is not claiming to implement the entire feature set of IPSec. They're just claiming to offer basic but strong crypto and authentication. If you want more, you are likely using other algorithms like SSL and SSH over the overlay network.

Yes, that comes with a performance penalty, but it's also defense in depth. It's better to trust multiple layers of crypto with independent implementations at each layer so that a compromise of one does not destroy your entire security posture.

It all comes down to the question of how paranoid you are. No encryption will give you the best performance, but no security. If you want maximums security you can run SSL over IPSec over Weave with different sets of keys and different ciphers at each level. Bonus points for generating those keys on different air-gapped hardware, etc.


> compilers, language design, machine learning, databases with strong ACID guarantees, etc.

Compiler design isn't that hard. A perfect optimizing compiler is damn nearly impossible, but good enough is easy. LLVM makes good enough compilers pretty easy, see the number of new languages that get posted to HN every month!

Machine Learning is hard to do right for non-trivial cases, but the only risk is you waste your investor's money and your customer's time, you don't risk identity theft (unless you are using machine learning to write crypto code maybe? :) )

Databases, yeah, everyone screws those up.

The real key is how many people are trying to break your system though. Crypto is exposed, your DB layer can have protections put on it to sanitize your data and rate limit how fast stuff comes in. You can clean up the data that goes into your machine learning algorithm (or use one that is resilient to x% of malicious data).

None of those defenses depend upon defending attacks of context switch timing in the CPU leaking data from a CPU that was releases 2 years after your code shipped through QA!

(and yes new CPU designs can cause problems in any code! But Intel and AMD work hard to avoid the major cases!)


No, it was clearly understood when SSL was developed, as shown in http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse.... The real reason why crypto is hard is that it requires an enormous amount of extremely specialized domain knowledge, and very subtle differences between two protocols can make the difference between success and failure. ISO regularly standardizes broken crypto.


I'm tired of all this talk about passive agressive.

How about a different explanation: After answering time and time again on twitter he found out he had other things to do and played the "show me the code" card?

And yes noobs[0]: Show me the code is a valid card in programming discussions.

[0]: here I am purposefully rude, feel free to take offense if you think it helps - or feel free think twice or even laugh with me.

Open source and computing culture has to a certain degree been a safe haven based on technical skills. Lets try to keep it that way as long as possible, shall we?


I don't view this kind of comment as a "fuck you". I think this says more about your outlook than it does theirs.

They're letting you know that they have their own priorities, but they're still receptive to your ideas, which is absolutely fine. What is wrong with that?


"Submit a patch" may be "fuck you" but that's not what he said, it was more like: "It's not as easy as you think. You can prove me wrong by submitting a patch.". This second is not reasonably interpreted as "fuck you".



I find your attitude the ruder. Users of paid products have the right to complain about stuff like that; it's literally what they paid for. Users of open source projects have no such right: if you know what to do, why not make yourself useful instead of bitching out someone who's volunteered their free time to make your life easier? I have very little patience with armchair pundits myself, if you submit a pull request we can happily have a conversation, but everybody's a critic and some of us are trying to get things done.


Nonsense. Users of free and open source software have every right to point out flaws in the design and implementation of that software. And this is an invaluable service to the authors and community. While finding and fixing an issue is nice, it's certainly not required, and not everyone capable of identifying issues has the time, ability, and inclination to fix those issues.

Furthermore, the conversation at issue was initiated by a community member asking why Weave's authors chose to implement their own security mechanism. The point of this kind of question is to assess whether the authors had good reasons, bad reasons, or no reason at all behind a questionable decision. This helps determine whether the effort to resolve the issue would be well-spent. If the authors aren't convinced that other solutions would be superior, they may be unwilling to accept a contribution, and you are potentially wasting your time producing a patch.


"why not make yourself useful instead of bitching out someone who's volunteered their free time to make your life easier"

Because as soon as you've found issues with more than, say, 3 things, you no longer have enough of your own free time to volunteer to solve the problem in a better way, let alone whatever you were already working on. Do you honestly believe that criticism has no value?


Complaining on twitter is not the same as finding an issue! Criticism has value, but not all commentary deserves equal weight or time before it is reasonable to request reciprocal effort.


It has vanishingly little and there's certainly no shortage of people handing it out for free. There's a reason for aphorisms such as "talk is cheap" and "my two cents". You seem to value your own time extremely highly; where's the respect for others?


You think security domain experts don't have the "right" to "bitch" (or perhaps, say, "inform") about potential security problems?

I understand you're trying to "get things done" but crypto is an area where you have to tread carefully, and talking down or ignoring people trying to inform you about security flaws is only encouraging the development of insecure software.


I'm pretty sure the point is more that - had Weave used a standard and already-vetted encryption method instead of rolling their own crypto - they could have put that free time into more useful things instead of now having to maintain yet another crypto implementation on top of their main project.

This isn't to say that there's never room for improvement in the crypto space - I personally disagree with the assertion that rolling one's own crypto is inherently bad in all cases, and instead believe that we need a maximum of innovation attempts now so that they can be evaluated and audited and identified as useful - but unless you're actually fixing a problem, Not-Invented-Here syndrome is dangerous and a waste of time better spent elsewhere.


We did not roll our own crypto. We used NaCl. The rationale is explained here - http://weaveworks.github.io/weave/how-it-works.html#crypto We agree that other approaches are possible, but this is the one we picked for our first version.


Weave had their reasons. I don't profess to understand the space well enough to chime in, but that much is clear from the twitter excerpt.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: