6 ms·

On Hemlis's front page: "We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand ho

On Hemlis's front page: "We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand however, is that Open Source in itself does not guarantee any privacy or safety. It sure helps with transparency, but technology by itself is not enough." They have no intention of releasing the source code. Use https://www.surespot.me/ https://www.surespot.me/ instead, it does the same stuff, already exists, and is released under the GPL (v3).

perlpimp 13y ago
Sounds like a trap to me, not having the source code. Maybe it works for now but investing trust as things are now I'd rather go with opensource client. Trust must be earned, so far it they brag about way they made tech work with a patched version of android - they don't really put forth anything that will give them credibility as a very secure protocol. Claims without proof are just that.
- tptacek 13y ago
  The track record of open source cryptography is bad.
  - dublinben 13y ago
    The track record of closed source cryptography is worse.
    - IanChiles 13y ago
      cough cryptocat cough
      - atmosx 13y ago
        The cryptocat issue can be viewed sideways: * Open source applications are bad, see what happened to cryptocat? * Open source is awesome! Look what happened to cryptocat! If cryptocat was closed-source... would ever be noticed? I wonder...
        tptacek 13y ago
        People insist on looking at this through their default prism of "closed source bad, open source good". But people with crypto experience have other prisms; for instance, "competent, well-vetted crypto" versus "amateur enthusiast crypto". Sometimes open source is also competent and well-vetted, but vetting is expensive, and there is a lot of amateur crypto out there.
        nocoment 13y ago
        > Sometimes open source is also competent and well-vetted, but vetting is expensive, and there is a lot of amateur crypto out there. You seem to be implying that one must be a hobbyist in order to write incompetent crypto software with no or incompetent review and tend to need company resources to get quality code reviews. Having crypto is often an important checkmark and tack on for shipping a product and usually no one in the product group is competent to analyze the security of the way they tacked on encryption. If a few in the larger company are competent, they will avoid reviewing these projects. Being the engineer everyone associates with delays and frustrations doesn't do much for you and there will never be any proof of the costs you may have prevented. The few better than I know how to criticize implementations that I have seen haveusually had considerable cross company and university involvement. That usually means open source or a lot of NDA and complex license agreements for cross organization code sharing.
        tptacek 13y ago
        I have no idea what you're trying to say here, but just a random stab at responding: my perspective in this discussion comes from managing a consulting practice that, among a few other things, specializes in assessing the security of cryptographic implementations.
        nocoment 13y ago
        I've been in a role of evaluating security vulnerabilities on security products and features from many different origins.. All I am saying is that I am in a position to estimate ~9/10 of everything critically exceeds the competence of its authors to safely combine features and security. So a primary explanation for failure that only applies to 40%(60%?) of the market doesn't sound right to me. So either we disagree considerably on proportion of software that is poorly implemented or you are saying the majority of commercial software is also written by hobbyists?
    - wglb 13y ago
      For example?
      - tptacek 13y ago
        I stifled the urge to say the same thing, but then realized that I'd lose the evening to defining what "mainstream" meant, after people dredged up random examples of snake oil from Schneier blog posts; not to mention the inevitable rehashing of the "beware custom algorithms and 390244 bit keys" thread, which is going to have to happen now because bringing up crypto truisms from the late-90s makes people feel smart.
        tga_d 13y ago
        You're being unfair and you know it. Lavabit, the RSA fiasco, Apple's imessage crypto, etc. are all perfectly mainstream examples of closed-source crypto done wrong. As you said yourself, the only thing that conclusively makes a difference is if the crypto is "well vetted," having the source available is simply a means of making this easier. Classifying the quality of crypto-implementations based on the source model alone ("The track record of open source cryptography is bad.")is just disingenuous.
        tptacek 13y ago
        No, I'm not being unfair. I don't think "open source" versus "closed source" has much at all to do with how secure a cryptosystem is. I do think having Trevor Perrin and Moxie Marlinspike working on your crypto design has a lot to do with how secure a cryptosystem is.
        tga_d 13y ago
        Yes, you are being unfair. You can't say I don't think "open source" versus "closed source" has much at all to do with how secure a cryptosystem is (somewhat agreed) while simultaneously saying The track record of open source cryptography is bad (utter nonsense and misleading), unless your point is that closed source cryptography has an equally bad record.
  - uniclaude 13y ago
    Please explain for those of us who are not good enough in the field (I'm genuinely asking). I was under the impression that software like GnuPG and OpenSSL could be considered safe, so seeing a security professional warning about a negative track record of open source cryptography is worrisome. What exactly should we be careful of when it comes to open source cryptography?
    - lvh 13y ago
      Not all open source code is broken; just a lot of it is. I think tptacek is trying to say that open source vs closed source is a mediocre predictor of the quality of a cryptosystem :)
  - illicium 13y ago
    OpenSSL
tptacek 13y ago
You'd be making a pretty big mistake to opt for something that hadn't been vetted, over TextSecure, simply because of the availability of source code.
- deleted 13y ago
  [deleted]
- mike-cardwell 13y ago
  Personally, I've used both, but settled on SureSpot for the moment. SureSpot uses data exclusively, which is cheaper than SMS for me. Although I understand that TextSecure now has (or will be getting soon) a data channel. So I'll definitely take another look. Moxie has proven himself to be more than capable of building such a system, but the author of SureSpot seems more than competent too. See the section titled "Technical Overview" on: https://www.surespot.me/documents/how_surespot_works.html https://www.surespot.me/documents/how_surespot_works.html Interesting fact: TextSecure wasn't made open source until it was bought by Twitter: https://dev.twitter.com/blog/whispers-are-true https://dev.twitter.com/blog/whispers-are-true - IIRC, prior to this the website claimed it was open source, but offered no way of getting the source, and if you asked for it, you would find out it was only given to trusted third parties to perform security reviews.
em3rgent0rdr 13y ago
Surespot depends on a bunch of google play services and is officially distributed on google play. Is there a way to install pre-compiled surespot apk outside of google play for those that don't install proprietary google code on their phone? I noticed that the open-source android apk repository F-Droid can't distribute it for this reason: https://f-droid.org/forums/topic/surespot-encrypted-messaging/ https://f-droid.org/forums/topic/surespot-encrypted-messagin... (Side note: moxie prohibits TextSecure on F-Droid as there is no forced auto update like google play. I currently have to download and compile the TextSecure source code myself, which is no biggie, but as a CM user, I'm definitely excited about this integration!)

perlpimp 13y ago

Sounds like a trap to me, not having the source code. Maybe it works for now but investing trust as things are now I'd rather go with opensource client. Trust must be earned, so far it they brag about way they made tech work with a patched version of android - they don't really put forth anything that will give them credibility as a very secure protocol. Claims without proof are just that.

tptacek 13y ago
The track record of open source cryptography is bad.
- dublinben 13y ago
  The track record of closed source cryptography is worse.
  - IanChiles 13y ago
    cough cryptocat cough
    - atmosx 13y ago
      The cryptocat issue can be viewed sideways: * Open source applications are bad, see what happened to cryptocat? * Open source is awesome! Look what happened to cryptocat! If cryptocat was closed-source... would ever be noticed? I wonder...
      - tptacek 13y ago
        People insist on looking at this through their default prism of "closed source bad, open source good". But people with crypto experience have other prisms; for instance, "competent, well-vetted crypto" versus "amateur enthusiast crypto". Sometimes open source is also competent and well-vetted, but vetting is expensive, and there is a lot of amateur crypto out there.
        nocoment 13y ago
        > Sometimes open source is also competent and well-vetted, but vetting is expensive, and there is a lot of amateur crypto out there. You seem to be implying that one must be a hobbyist in order to write incompetent crypto software with no or incompetent review and tend to need company resources to get quality code reviews. Having crypto is often an important checkmark and tack on for shipping a product and usually no one in the product group is competent to analyze the security of the way they tacked on encryption. If a few in the larger company are competent, they will avoid reviewing these projects. Being the engineer everyone associates with delays and frustrations doesn't do much for you and there will never be any proof of the costs you may have prevented. The few better than I know how to criticize implementations that I have seen haveusually had considerable cross company and university involvement. That usually means open source or a lot of NDA and complex license agreements for cross organization code sharing.
        tptacek 13y ago
        I have no idea what you're trying to say here, but just a random stab at responding: my perspective in this discussion comes from managing a consulting practice that, among a few other things, specializes in assessing the security of cryptographic implementations.
        nocoment 13y ago
        I've been in a role of evaluating security vulnerabilities on security products and features from many different origins.. All I am saying is that I am in a position to estimate ~9/10 of everything critically exceeds the competence of its authors to safely combine features and security. So a primary explanation for failure that only applies to 40%(60%?) of the market doesn't sound right to me. So either we disagree considerably on proportion of software that is poorly implemented or you are saying the majority of commercial software is also written by hobbyists?
  - wglb 13y ago
    For example?
    - tptacek 13y ago
      I stifled the urge to say the same thing, but then realized that I'd lose the evening to defining what "mainstream" meant, after people dredged up random examples of snake oil from Schneier blog posts; not to mention the inevitable rehashing of the "beware custom algorithms and 390244 bit keys" thread, which is going to have to happen now because bringing up crypto truisms from the late-90s makes people feel smart.
      - tga_d 13y ago
        You're being unfair and you know it. Lavabit, the RSA fiasco, Apple's imessage crypto, etc. are all perfectly mainstream examples of closed-source crypto done wrong. As you said yourself, the only thing that conclusively makes a difference is if the crypto is "well vetted," having the source available is simply a means of making this easier. Classifying the quality of crypto-implementations based on the source model alone ("The track record of open source cryptography is bad.")is just disingenuous.
        tptacek 13y ago
        No, I'm not being unfair. I don't think "open source" versus "closed source" has much at all to do with how secure a cryptosystem is. I do think having Trevor Perrin and Moxie Marlinspike working on your crypto design has a lot to do with how secure a cryptosystem is.
        tga_d 13y ago
        Yes, you are being unfair. You can't say I don't think "open source" versus "closed source" has much at all to do with how secure a cryptosystem is (somewhat agreed) while simultaneously saying The track record of open source cryptography is bad (utter nonsense and misleading), unless your point is that closed source cryptography has an equally bad record.
- uniclaude 13y ago
  Please explain for those of us who are not good enough in the field (I'm genuinely asking). I was under the impression that software like GnuPG and OpenSSL could be considered safe, so seeing a security professional warning about a negative track record of open source cryptography is worrisome. What exactly should we be careful of when it comes to open source cryptography?
  - lvh 13y ago
    Not all open source code is broken; just a lot of it is. I think tptacek is trying to say that open source vs closed source is a mediocre predictor of the quality of a cryptosystem :)
- illicium 13y ago
  OpenSSL

tptacek 13y ago

You'd be making a pretty big mistake to opt for something that hadn't been vetted, over TextSecure, simply because of the availability of source code.

deleted 13y ago
[deleted]
mike-cardwell 13y ago
Personally, I've used both, but settled on SureSpot for the moment. SureSpot uses data exclusively, which is cheaper than SMS for me. Although I understand that TextSecure now has (or will be getting soon) a data channel. So I'll definitely take another look. Moxie has proven himself to be more than capable of building such a system, but the author of SureSpot seems more than competent too. See the section titled "Technical Overview" on: https://www.surespot.me/documents/how_surespot_works.html https://www.surespot.me/documents/how_surespot_works.html Interesting fact: TextSecure wasn't made open source until it was bought by Twitter: https://dev.twitter.com/blog/whispers-are-true https://dev.twitter.com/blog/whispers-are-true - IIRC, prior to this the website claimed it was open source, but offered no way of getting the source, and if you asked for it, you would find out it was only given to trusted third parties to perform security reviews.

em3rgent0rdr 13y ago

Surespot depends on a bunch of google play services and is officially distributed on google play. Is there a way to install pre-compiled surespot apk outside of google play for those that don't install proprietary google code on their phone? I noticed that the open-source android apk repository F-Droid can't distribute it for this reason: https://f-droid.org/forums/topic/surespot-encrypted-messaging/ https://f-droid.org/forums/topic/surespot-encrypted-messagin... (Side note: moxie prohibits TextSecure on F-Droid as there is no forced auto update like google play. I currently have to download and compile the TextSecure source code myself, which is no biggie, but as a CM user, I'm definitely excited about this integration!)