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)

"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.

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).

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.

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