Comment by secfirstmd | Hacker News Reader

Comment by secfirstmd | Hacker News Reader

So in the age of Edward Snowden this is all they say about encryption...

"Are Messages And Calls Encrypted? Yes. Wire uses industry-standard encryption on all of your Wire messages and calls."

"WHAT SECURITY MEASURES DO WE TAKE TO SAFEGUARD YOUR PERSONAL INFORMATION?

We are concerned about safeguarding the confidentiality of your information. We provide physical, electronic, and procedural safeguards to protect information we process and maintain. In addition, we restrict access to personal information to Company employees who need to know this information in order to develop, operate and maintain the Service."

Come on guys...how can anything this vague be trusted?

And by European they mean Swiss, so not specifically EU.

One of the typical evasive phrases...

From the Guardian Article:

"Locating its head office in Switzerland was Wire’s first decision taken on security grounds. “If someone is interested in accessing our user data, there’s a formal and well-regulated process in Switzerland for that. They’re very mindful of privacy, and the same is true in Germany."

Swiss naturally implies safety for many people (which is deceptive...real, verifiable, audited, end to end encryption is safety), for anyone unsure about the reality of "Swiss" cooperation with NSA since the 70s, read about Crypto AG

http://mediafilter.org/caq/cryptogate/

For those wondering about "Swiss privacy laws," if you are a foreign national you are effectively fair game

http://en.wikipedia.org/wiki/Onyx_%28interception_system%29

http://www.iclg.co.uk/practice-areas/telecoms-media-and-inte...

Unfortunately, even if they DID specifically list out all the security measures that they used, someone would still complain because it isn't completely open source. The previous company I worked for not only had legitimate encryption for anything private we received from the user (e.g.: email passwords) so that nobody at the company could ever read them, but also had some (if I remember correctly) good documentation on the site listing out exactly what we were doing. The founder of the company even commented with the specific technical details when our product was linked to on HN, and people still weren't happy.

While I sympathize with what you're saying, nothing is going to make people who actually care happy with whatever security a company puts in place. Unless that company releases their source code for everyone to see. Which I would hope most people would be reasonable enough to realize why that's usually impractical. (see the previous HN post about the guy who shut down his business and was debating open sourcing his entire codebase, and all the problems he would have had to tackle to do so)

There is another option - matrix.org is a new open standard for real-time communication (with encryption) in an open, federated ecosystem.

That means you can run your own server and encrypt your own data, and the encrypted data can still be sent to other servers in the federation.

To your point about open source, if something like this can take off it needs to be fully open and transparent, without fees or central data ownership - which is why matrix.org is a non-profit organisation and the standard open source.

(disclaimer: I'm involved with matrix.org)

From the homepage: > Send and receive extensible messages with optional end-to-end encryption

Why would encryption ever be "optional"?

Back in the day it was often optional due to the additional processing that it required.

That was indeed a thing in the days before AES-NI or simply having 1.4 billion transistors on a chip.

But in my day we've been spending years fighting this sort of short-sightedness: https://www.ietf.org/mail-archive/web/rtcweb/current/msg0274...

Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is:

curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo...

...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.

Is that the same way I can always insist on only ever receiving PGP-encrypted e-mail?

Not quite - as PGP is a pita to use, and not a formal part of the SMTP spec. So refusing to read non-PGP would be suicide. But if it was considered table stakes to implement the crypto option of the spec, and all the decent Matrix clients out there did so and sent end-to-end encrypted by default, then it'd naturally become the default. In other words, if you gracefully upgrade chats between capable clients to be end-to-end by default, everybody wins.

If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-p...

In the absence of some forcing function, the trend is for it to get worse, not better.

There are already FOSS replacements for Skype, such as Tox. The fact is that if every line of code can't be inspected then the software can't be considered secure, and we're forced to put blind faith in a faceless corporation, which is understandably not acceptable for many people. I don't really care if you think this is "practical" or not. That's simply the reality of the situation. Proprietary == insecure.

If a company is unable to profit off of making FOSS software then they can go ahead and keep it closed source, but they should not be claiming that their software is secure when their claims cannot be verified. That's simply dishonest, and only proves the critics right about their trustworthiness.

I don't think it's as black and white as all that. This reads like the equivalent claim the NSA makes along the lines of, "if you have nothing to hide, why can't we record every facet of every communication and store it forever?" Business relationships run on trust. Claiming your software is secure when it is to the best of your knowledge is not dishonest.

That's a false dichotomy. Not wanting personal conversations recorded is called discretion, a form of wisdom. Not wanting technical details of a product published is primarily a way to gain a competitive advantage, either against other businesses or against potential threats.

You're making the baseless (and some might say naive) assumption that it is secure to the best of their knowledge. If they really wanted to build trust then they would prove it and leave no doubt in people's minds.

"Dear citizen, you're asking us to make the baseless assumption that you're innocent until proven guilty, if you really want to build trust you'll let us monitor you 24/7 and leave no doubt in our mind."

You're making an assumption of guilt. The fact that something isn't open source doesn't inherently make it insecure.

I'm not making any assumptions as to their motives; I have not accused them of any wrong doing. As far as I'm concerned, they might be working in good faith or they might not be. That's not good enough when it comes to security. You're incorrect with that last sentence as I and others have pointed out already.

It doesn't make it trustworthy either. When speaking of encryption algorithms, not publishing a new algorithm for peer reviewing is unthinkable. This is also not about judgment - I do consider people to be innocent until proven guilty, but do you trust people you don't know with issues that could harm you? Besides companies are not people, we are taking about a commercial entity here that wants to sell something. And people get to vote with their wallet and opinions, depending on their needs and I see nothing wrong with that.

"And people get to vote with their wallet and opinions, depending on their needs and I see nothing wrong with that."

I was thinking the same thing! But you seem to be assuming guilt and I am not. Honestly, I can see it both ways. It just seemed spurious to me to state that if we don't know it's good, it must be bad.

I would argue that, theoretically, proprietary can be secure. A code base can be made secure by highly experienced engineers who are paid to make the code secure. You might never be able to see the code, but it could still be secure. The problem is that you can never actual verify how secure the proprietary solution is. So whether or not it is secure, you don't trust it. (there are even some interesting arguments to be made about the security of any solution that deals with some kind of user input. my previous boss stipulated that the only way to have a truly secure email client is to have some third-party, verified library that takes all the input, and spits out encrypted data to whatever program deals with email servers, without the program dealing with email servers ever seeing that input in plain text form because who knows what it might do with it)

On the other hand as well, open source most certainly does not mean secure. I don't even have to argue to make this point, I merely have to point out Heartbleed or Shellshock.

I don't even have to argue to make this point, I merely have to point out Heartbleed or Shellshock.

The reason both were found and had the absurd propaganda campaigns behind them as they did that are the only reason you can even name them to begin with, is precisely because the underlying software was free.

On the other hand, let's name drop another vulnerability and its exploit: SMBRelay. Took 7 years after it was made public to introduce an incomplete and partial fix. Still exploitable to this day, 13 years later.

So what it boils down to, is that both open source and closed source software can have bugs lingering in them for years that go unnoticed and/or unfixed.

Yes, proprietary can be secure. But my question to you is why bother?

As a business model open-source arrangements such as Red Hat or the countless Hadoop services show that you don't really need to lock down the source code to create a successful business around it.

With communications software, the costs a closed-sourced software with magical trust-us crypto getting fully compromised is incredibly high. If people can't trust their basic tools to be private, nor be able to verify it, than they can't assume any conversation they have is private. That's a scary world IMO.

This is particularly true for broken encryption more than the presence of memory exploitation such as Heartbleed or Shellshock.

Yes, in theory it is possible. However even 100% secure proprietary software must be assumed to be insecure, because we're still running on blind faith, which is patently stupid for anyone who requires security.

You run OpenBSD, don't you? (To be fair, their approach since the 90s seems a lot more reasonable now)

No, my views are not based on my own needs or paranoia. As a security-oriented software developer I recognize that software that claims to be secure needs to deliver, because people like Snowden, Assange et al. may be relying on it some day.

While you can argue that some piece of open source software can be more insecure than a proprietary alternative, auditing a piece of software requires access to the source code and that is mandatory. And with open source everybody can audit with no restrictions. Yes, OpenSSH is a piece of shit, but how do you think it was discovered, from 2 independent parties no less.

Then there's another effect that I like - after the initial patch was released, the story went public, we got notified immediately, then we could discuss about what caused it and see the actual commits and who did it. Such a catastrophe can sink a company, therefore you never see such post mortems for proprietary stuff. And yes, even I as a developer cannot audit software for security, but the point is that I could hire somebody else to do that for me, like the Finnish company that discovered Heartbleed.

So yeah, there is no concrete proof that proprietary stuff is less or more secure than open source, but the point is that we'll never know, because nobody can know how secure something is without looking at the source code.

OpenSSH or OpenSSL? I thought OpenSSH was pretty solid, forgetting the fact that configuring it isn't as straightforeward as one would hope.

Sorry, I meant OpenSSL. It was a typo.

Tox is not a Skype replacement. For example:

- Skype is "everywhere" (Windows, Windows RT, Windows Phone, OS X, iOS, Android, Linux, FreeBSD, Blackberry, XBox One) and opposed to a handful of places (Windows, Linux, OS X, Android, iOS, FreeBSD, OpenIndiana). Plus Outlook.com's Skype implementation supports most platforms with a HTML5 browser.

- Landline/cellular phone calling. Text message sending.

- Caller ID, Voicemail, etc.

- Skype Numbers (i.e. buy a landline phone number people can call your Skype via, which is insanely useful for SMBs and individuals alike).

- Tox's feature list is largely a myth. Most clients are missing major Skype features and none support all of them, see this: https://wiki.tox.im/Clients#Features

People who think Tox is a Skype replacement aren't Skype's core demographic. The landline/cellular/etc functionality is heavily used by many and nothing that claims to be a replacement can be taken seriously if it lacks that.

tox.im website is not working. Am I looking in the wrong place?

>> the previous HN post about the guy who shut down his business and was debating open sourcing his entire codebase, and all the problems he would have had to tackle to do so

link please?

I think the poster may be referencing this submission: https://news.ycombinator.com/item?id=8641867

Specifically, the replies of the submitter in the comments

That's the one, thanks! Sorry, should have linked that in the first place.

No, much larger than the issue of open-source is that we already have dozens of major communication protocols that are not based on open standards or that do federation (one implies the another).

XMPP does OTR for example. And you know, the cool thing about an open standard is that it can have many clients. Throw federation in the mix and then many people will actually find it desirable.

Otherwise it's just a matter of being new and shiny. Because other than that, I don't understand how this new messenger competes with Hangouts, Skype, FB's Messenger, WhatsApp, Viber, iMessages, FaceTime, Snapchat, Y! Messenger, Lync, HipChat, Slack, IRC in general, or plain old calls and SMS messages, which are pretty cheap lately in Europe (at least in my country). Note that I enumerated about a dozen of popular alternatives.

I expect new entries to brag about something more than UI. Because my phone has the best UI ever - I just call somebody and that somebody responds because everybody has a phone number. I want to see open standards, federation and encryption, because otherwise new entries are useless for me.

So another proprietary walled garden that promises to keep my conversations secure, cross their hearts? No thanks.

XMPP and OTR are not workable for mobile devices. The protocol structure assumes a consistent background connection that doesn't get killed, something that is relatively cheap to do on the laptops and desktops it was designed for, but is expensive battery wise for mobile devices.

Go download an OTR client for iOS, like cryptocat and notice how it pings you after 10 minutes that you have to re-open the app to keep on receiving messages! It's because iOS does not allow you to keep an app running in the background indefinately for battery reasons. This is required for the XMPP / OTR model to work.

You need a protocol of some sort that would work properly with mobile, and I think textsecure is it.

You can develop an xmpp client for IOS that does not ping you every 10 minutes (or ever). You have to register the socket used for XMPP for VOIP purposes and IOS will happily comply with that. Been there, done that

This still isn't power-efficient. On phones you should be using push notifications instead of holding a socket open.

OTR kind of sucks, partly because of what you mentioned.

I'm trying to introduce the Axolotl ratchet (behind TextSecure's security) into XMPP:

https://github.com/rakoo/goax

The Axolotl ratchet provides true asynchronicity so you don't need to keep the link open forever. You don't even need the other party to be up; the message can be stored on either server and forwarded when the recipient connects, and the recipient will only decrypt the message at this moment. This is what we need.

Guardian article has a bit more details regarding the privacy and encryption. http://www.theguardian.com/technology/2014/dec/03/wire-commu...

Agree - I wonder if Adobe's block mode 3DES was 'industry standard'.

Saying "we use encryption" isn't any good; this isn't 1996. People need to have the details available if they want them (a little "More Information" link going to a page showing their actual security model, list of ciphers and modes of operation, etc. would do).

Does it really matter whether they have encryption a or b? If it is poorly implemented it is unsafe.

So either you trust them to do a good job or you don't. Whether someone in marketing knows the name of your favorite encryption doesn't really change that.

Agreed, open source, audited etc is obviously better but the least they could do is tell us a little more.

One hint of whether that they've poorly implemented it is that they didn't care to choose a preexisting algorithm, or they chose a preexisting algorithm with known weaknesses, or that they chose an algorithm with fiddly parameters without addressing that.

I'm much more likely to trust if various indicators suggest they're being sane, reasonable and knowledgeable.

Well, they can quote the most advanced encryption algorithm, but you still can't be sure if they have really used it unless they share their code.

Bottomline: You either trust them or you don't.

One reason for them not sharing the details could be that they want the potential hackers to keep guessing rather than making their life easier (No encrytion is foolproof)

Kerckhoff, 1883: "[T]he security of a system should depend on its key, not on its design remaining obscure."

Security by obscurity isn't sufficient by a long shot -- and you can't rely on it -- but that doesn't mean it's without value.

Obscurity may only buy you time while you fix your security problems (before someone stumbles across the mistake you've made), but if you can manage to correct flaws before they are exploited, well, that's a good thing.

That said, Wire would do better to share enough details to show that they are putting real work into security and encryption. Compare Wire's security detail with something like Crypho's: http://www.crypho.com/features.html

They're still omitting plenty of details in their implementation, but it's obvious they have a strong focus on security. Wire doesn't really say anything (yet).

"Bottomline: You either trust them or you don't."

That's not true at all. Trust isn't blind faith. Their choice of algorithm, and other factors they can disclose tells a lot about their understanding.

"One reason for them not sharing the details could be that they want the potential hackers to keep guessing rather than making their life easier (No encrytion is foolproof)"

This is security by obscurity, an example of a poor choice. Overall, your statement says more about your lack of understanding of software security than anything else; as their statements can about theirs.

Security by obscurity is a perfectly valid security mechanism - to be used in conjunction with other security mechanisms.

There is no security silver bullet - a properly secured system is security by many strategies. One of those strategies may indeed be obscurity.

Trust isn't binary.

You could perfectly well trust that they're earnest without trusting that they're competent. If that's your position, which is resonable, given enough information you can alleviate some of the competency concerns.

That said, given the landscape they're working in, it's hard to trust any commercial entity is genuinely willing and able to keep your communications secure.

>Trust isn't binary.

Exactly.

Transparency in how you secure your shit is basic diligence, then the user trusts that that is accurate and properly implemented. I'd never use a service that didn't do that; just as I have a firefox addon (CipherFox) that shows what cipher a site is on, so if I see, for example, RC4, I know it's secure in name only.

Why do you say they didn't care to use a preexisting algorithm? They claim to be using industry standard encryption, that means they are using existing algorithms that have been vetted and proven to be safe (if properly implemented).

Again, see Adobe. They might have theoretically bullshitted 3DES as being 'industry standard', even if a very old standard.

Choosing a standard protocol indicates that you aren't completely inept when it comes to encryption.

Disagree, depending on how strong you mean the word "indicate" to be.

Exactly. Complying with "all messages encrypted" is equivalent to simply using HTTPS (and equivalent for voice). But this doesn't make it safe against MITM attacks, side-channel attacks and government subpoenas!

Judging from their FAQ, it seems that they encrypt voice end-to-end, but messages only between the client and the server: https://support.wire.com/hc/en-us/articles/203122500-Are-mes...

They have features like syncing the read status of messages, so I assume their server knows about all messages and conversations (although maybe not the contents if encrypted properly).

You should consider that most other messengers offer no such promises, even vague ones.

That doesn't make it any better. Moreover, a false sense of security does even more harm to the users.

I'd prefer a honest "We are no security experts, don't use this for critical conversations!"

Telegram seems to put their money where their mouth is.

I think Telegram is the best messaging app out there.

I think once Open Whisper Systems merge their products into Signal, that is going to be the best out there...Hopefully they will get the uptake they deserve.

My standard gripe with OpenText (or WhatsApp etc) is the identifier. A phone number sucks.

a) I hate the discoverability. Just because I install an app doesn't mean that my ex from ten years go should see that I'm online. Heck, my mom or aunt don't need to see me showing up in the address book either.

b) Desktop clients. Tablets with wifi only.

There are serious concerns with Telegram encryption/privacy. See discussion: https://news.ycombinator.com/item?id=8686868 for example

I'm not sure.

They offer these 'challenges', but other than that? For me, this comment of yours would we something I'd agree with if

- Telegram would start out with a protocol that works/is 'accepted' (OTR, TextSecure)

- Would make chats encrypted by default/all the time

That'd be awesome. Given that they seem to know a bit about cross-platform development and design the result might be extremely interesting. Right now? I'm not convinced.

What? Skype offers the exact same vague promises, and they are even technically true.

Did they also mention their business model anywhere ? Also how the European laws protects us about anything ?

Quoting http://www.theguardian.com/technology/2014/dec/03/wire-commu...

"It’s in our terms of use: we’re not going to look at your data and cultivate it for advertising," said Christensen. "We’re not going to put advertising in the client. My head of design would kill me! It’s more about finding the right kind of opportunities that are additive to the user experience, and that they’re motivated to pay for. We’ve found what we think are a couple of good ones."

> Also how the European laws protects us about anything ?

Probably more than US laws anyway.

I assume this is a joke? The US doesn't have mandatory data retention laws.

The problem with abiding by European privacy laws is that if you're not European, you don't count. So if you're not European, there may as well be no privacy at all. You're more or less on your own - just the same as with American privacy laws.

If they can prove one end of the conversation is not American or not in the U.S. you're recorded... but because it's so hard to do that on the fly, you're recorded anyway and they'll figure out the legal repercussions later... by hiding it, diverting the question or flat out lying about it.

It's a shame, this looks on the surface like a great product. But I agree with the point made earlier: In the age of Snowden, statements as vague as "Wire interactions are secure and we comply with European privacy laws and regulations." aren't enough for anyone to stake their security on.

The fact is, when it comes to communication security, the Government has proven themselves untrustworthy too many times for us to believe them anymore. Once could be written off as a mistake, twice, perhaps oversight wasn't good enough. But three, four, five times... the fact is, Governments have torpedoed any reasonable person's ability to trust them when it comes to looking after their privacy. So saying that you "comply with privacy laws and regulations" is no comfort. In today's political climate, if you want the trust of the people, you need to go above and beyond in the name of the people.

It will be trusted completely by their target market, which thinks Snowden is like, a real hero, but that PGP is not something they'd want to catch.

Also, their main site doesn't work without JavaScript. Come on ... having to execute custom code in the browser just to display a "Download" button?

I hope they applied more (security-related) common sense in their apps than in their website.

Processing foreign data is just as dangerous as processing foreign code. Don't lull yourself into complacency just because you have NoScript when your JPEG library is probably less sandboxed and audited than your JavaScript virtual machine. The whole idea of the Von Neumann architecture is that code is data and data is code. It is advantageous when you trust everyone, but now that you can trust noöne? What to do?

noöne? really? when did 'no one' become insufficiently clear?

Probably a typo. ‘Ö’ and ‘O’ a very close on a German keyboard.

perhaps, but in it i detect a New Yorker magazine-style use of the dieresis to separate vowels into syllables that a reader might be inclined to pronouce together as a single sound, e.g.: reëlect for re-elect.

This is the correct interpretation. But it is actually slightly nuanced; I'm such a bad speller that, even as a native English speaking adult of 30 something, I had to look up no one. Wiktionary has noöne as an "alternative spelling" and I do like The New Yorker...

Based on past comments I'd expect the author to have the en_US layout (or something entirely different) and probably - now taking a guess here - even without umlauts.

I'm German and use en_US here, so for ö I'd need to compose a character manually. Which is probably what was mocked (whether that is right or wrong I do not know - I certainly cannot judge the style of writing of someone in his native language, as a foreigner myself).

I appreciate the great deal of thought you put into this. I feel like a mini-Internet celebrity of the minute.

You are entirely correct about needing compose to type the symbol, but I use it so rarely, that I just copy-pasted.

It's not an umlaut though, it's a different diacritic called diaeresis. It makes me feel like I'm speaking a more awesome language when I use it.

I'm glad you like the attention, but I have to admit that I didn't waste too much time on that post. Five minutes tops. :)

The 'not an umlaut' part doesn't seem to be relevant though, since we talk about the character composition. 'ö' is the same character both as o-umlaut and as o-diaeresis (I admit I checked if there's a different way to write the latter), so the argument is weird.

de_DE has a character 'ö' on the keyboard, if I use that as umlaut or not is a different problem.

Composing " and o (or whatever you use) produces what looks like o-umlaut to a German speaker - and my understanding was that you were 'attacked' (if you will) for going out of your way to write 'ö'. Whatever that character signifies here.

(I actually didn't know the name diaeresis, but the usage isn't uncommon here. I've driven my share of Citroën 2CVs in the past)

It indicates a new syllable. Very rarely seen this days, but it used to be used a lot. So the answer to your "when" is "a very long time ago, then people changed their minds"

I'm not complaining about the security implications of running JS code.

I'm complaining about security implications by introducing unnecessary complexity.

Reply on news.ycombinator.com