Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subrosa – An encrypted communication platform

subrosa.io

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Subrosa – An encrypted communication platform

#21

Post by vsakos »

phibit wrote: post #17
vsakos wrote: post #14

Earlier quoted context omitted.

I know it can be open source without git, but GitHub gives a lot of benefits. Also as I understood, you don't have Facebook, Twitter, Skype, Googe, Outlook, YouTube, and even HN account because NSA could one day transform everything against you?!

You misunderstood, completely. I never indicated that I don't have any FB/Twitter/Skype/... accounts. The idea of having a secure communication channel doesn't mean that ALL your communications have to be over secure channels, that would be ridiculous. Having the option to bank on a secure channel for conversations you deem private is a perfectly reasonable compromise. People in government agencies switch between ins…

So you're using FB to communicate with family and friends. As far as i know Facebook messages are not encrypted. Then NSA could use these messages against you (you said this). Am i right?

Re: Subrosa – An encrypted communication platform

#22

Post by jimktrains2 »

dublinben wrote: post #19
explorigin wrote: post #13

Earlier quoted context omitted.

This is not a "good" article. It's very hand wavey with lots of fud. For example, he talks about the chicken and egg problem of delivering javascript over an insecure connection and then solves it later with SSL/TLS (but he doesn't acknowledge that this is a valid solution). Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection. He talks about browser cache but says that ja…

>we're all harping on javascript when you can't download PuTTY over an SSL connection This shouldn't matter, and would just provide a false sense of security. You ought to be verifying the signature of any program you're installing before you use it. Since you're running Windows the point is probably moot, but it is possible to install software reasonably securely.

But those sigs are also coming over a non-ssl connection:-p

Honestly, whenever you download anything, evne over SSL, you're essentially trusting that the remote computer is not only who you think the computer is, but the person you expect to be controlling it is the only person controlling it.

Out-of-band communication built out-of in-person trust are really the only way around that (i.e. trusting someone who trusts the PuTTY devs and gets you the hash/sig).

Re: Subrosa – An encrypted communication platform

#23

Post by phibit »

vsakos wrote: post #21
phibit wrote: post #17

Earlier quoted context omitted.

You misunderstood, completely. I never indicated that I don't have any FB/Twitter/Skype/... accounts. The idea of having a secure communication channel doesn't mean that ALL your communications have to be over secure channels, that would be ridiculous. Having the option to bank on a secure channel for conversations you deem private is a perfectly reasonable compromise. People in government agencies switch between ins…

So you're using FB to communicate with family and friends. As far as i know Facebook messages are not encrypted. Then NSA could use these messages against you (you said this). Am i right?

Yep, you got it! Once again, I don't encrypt all my conversations because I'm making a tradeoff, but I would definitely prefer that they were all private. And again, having a distinct communication channel that was private would not be unwelcome.

Re: Subrosa – An encrypted communication platform

#24

Post by hluska »

explorigin wrote: post #13
hluska wrote: post #8

Earlier quoted context omitted.

That is such a good article and I cannot believe that I am just reading it for the first time now. Thank you so much for posting the article and your explanation of the two mutually exclusive statements. Crypto is just about the coolest thing I have ever heard of and I love learning about different types of attacks!

This is not a "good" article. It's very hand wavey with lots of fud. For example, he talks about the chicken and egg problem of delivering javascript over an insecure connection and then solves it later with SSL/TLS (but he doesn't acknowledge that this is a valid solution). Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection. He talks about browser cache but says that ja…

I think that I disagree, but I am not experienced enough to know what I don't know. Judging from your response, you know way more than me, so if it's okay with you, I will tell you why I disagree. Then, it would make my day (and help me a tremendous amount) if you would tell me why I am wrong.

a) The chicken and egg problem of delivering javascript:

I am far from being good at this stuff, but I am confident that, given the opportunity if you deliver .js (or anything else) over an insecure connection, I can modify the content before it ever reaches the user.

As you and the article state, you could solve this problem by delivering the .js file with SSL/TLS. But, if you do this, I presume that you would need to encrypt every single resource on the page. And, if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?

It strikes me that SSL/TLS are old enough to be well tested and researched, whereas if I wake up some morning and decide to implement my own crypto, I'm going to f* something up. I'd rather let smarter people do the heavy lifting.

But, I don't know what I don't know. What don't I know?

Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.

Please correct me if I am wrong, but if you can download PuTTY via an insecure connection, an attacker can just as trivially swap out the real version of PuTTY with a compromised version. That sounds really dangerous, but isn't that why the PuTTY developers add RSA/DSA signatures to their downloads page?

I would argue that if someone is smart enough to find a collision in both RSA and DSA, they can likely find easier ways to attack me than to swap out the real version of PuTTY with a compromised version.

What am I missing? disregard this question because I missed something very important - see my edit below

He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).

Thank you for this - I need to do some more reading. Though, wouldn't you get into the same problem where, unless you can control every single resource on the page (ie - serve it encrypted and make sure there are no XSS vulnerabilities) you can't guarantee that the browser is using the correct code? Then, doesn't that get back to the chicken and egg problem where if you're already implementing encryption, you don't need crypto in the browser?

--

Some of the ideas on that page (ie - the inability to generate strong random numbers) are kind of outdated. I believe that Opera uses a cryptographically secure Math.Random(). And, I think that there is an API to accomplish this in other browsers. window.crypto.GetRandom or something?

However, I still see all kinds of traffic with old versions of Internet Explorer (sorry to pick on IE). Wouldn't solving the crypto in a browser problem reliably require making everyone update to a modern browser?

I hope that I'm not coming across as being difficult, but I would love to learn and would appreciate any help you would provide.

Edited -- jimktrains2 wrote:

But those sigs are also coming over a non-ssl connection:-p

There goes my entire RSA/DSA argument! What a great thread...

Re: Subrosa – An encrypted communication platform

#25

Post by dublinben »

jimktrains2 wrote: post #22
dublinben wrote: post #19

Earlier quoted context omitted.

>we're all harping on javascript when you can't download PuTTY over an SSL connection This shouldn't matter, and would just provide a false sense of security. You ought to be verifying the signature of any program you're installing before you use it. Since you're running Windows the point is probably moot, but it is possible to install software reasonably securely.

But those sigs are also coming over a non-ssl connection:-p Honestly, whenever you download anything, evne over SSL, you're essentially trusting that the remote computer is not only who you think the computer is, but the person you expect to be controlling it is the only person controlling it. Out-of-band communication built out-of in-person trust are really the only way around that (i.e. trusting someone who trusts…

You only need to trust their signature to really be sure. That's why the Web of Trust aspect of PGP/GPG is so important. It's probably more valuable than the ability to encrypt a few emails.

Re: Subrosa – An encrypted communication platform

#26

Post by Scaevolus »

api wrote: post #11
Scaevolus wrote: post #2

Matasano's "Javascript Cryptography Considered Harmful" is yet again applicable. http://matasano.com/articles/javascript-cryptography/ These statements are mutually exclusive: End to end encrypted: Nobody, not even us, can read or listen into your conversations. Works everywhere: Visit subrosa.io from any computer. No download or install needed.

Everything this article says is true. That being said, it also applies to any regular application that can be upgraded automatically or that's upgraded at all by a third party. Anything you get off an app store can have its code switched out from under it with minimal and routine or in some cases even no user interaction. All someone has to do is compromise the signing key, which is probably not that hard in many cas…

Scarily true. The amount of damage malicious actors with keys can do is greatly magnified by the auto-update mechanisms that developers love.

Re: Subrosa – An encrypted communication platform

#27

Post by jtheory »

ctz wrote: post #9

"Nobody, not even us, can read or listen into your conversations." This cannot possibly be true, given they are the root of trust for establishing the recipient's authentic public key. Also, minified javascript really does not count as a source code release.

Quite right. If they were compelled -- e.g., "insert this backdoor or we'll imprison you" -- they might trivially serve up a tweaked version of their JavaScript to the one user the NSA was interested in.

And it wouldn't take a complicated tweak at all to sneak the real password (or some sufficient version of it) back to the server, after which point certainly "even us" can read & listen in to all of that user's conversations.

Re: Subrosa – An encrypted communication platform

#28

Post by technomancy »

CJefferson wrote: post #15
phibit wrote: post #12

Earlier quoted context omitted.

Can you explain how these two statements are mutually exclusive? These statements are mutually exclusive: End to end encrypted: Nobody, not even us, can read or listen into your conversations. Works everywhere: Visit subrosa.io from any computer. No download or install needed.

subrosa can choose at any time to send you javascript which will send your password back to them. You have no way of checking for this (well, except reading all the javascript, every time you log in)

Except it's a GPL'd web application, so you're free to run your own server.

Re: Subrosa – An encrypted communication platform

#29

Post by jtheory »

api wrote: post #11
Scaevolus wrote: post #2

Matasano's "Javascript Cryptography Considered Harmful" is yet again applicable. http://matasano.com/articles/javascript-cryptography/ These statements are mutually exclusive: End to end encrypted: Nobody, not even us, can read or listen into your conversations. Works everywhere: Visit subrosa.io from any computer. No download or install needed.

Everything this article says is true. That being said, it also applies to any regular application that can be upgraded automatically or that's upgraded at all by a third party. Anything you get off an app store can have its code switched out from under it with minimal and routine or in some cases even no user interaction. All someone has to do is compromise the signing key, which is probably not that hard in many cas…

Sure; but there's a world of difference between communicating with a webapp that claims to protect your privacy even from the NSA (but actually cannot) vs. "any regular application", which makes no such security claims, and from whom savvy users won't expect that kind of protection.

People with important information to communicate that they must protect from the powers that be (quite possibly to protect their own lives) will seek out secure methods; at the same time, the powers they're avoiding will be targeting secure communication methods.

Re: Subrosa – An encrypted communication platform

#30

Post by tptacek »

explorigin wrote: post #13
hluska wrote: post #8

Earlier quoted context omitted.

That is such a good article and I cannot believe that I am just reading it for the first time now. Thank you so much for posting the article and your explanation of the two mutually exclusive statements. Crypto is just about the coolest thing I have ever heard of and I love learning about different types of attacks!

This is not a "good" article. It's very hand wavey with lots of fud. For example, he talks about the chicken and egg problem of delivering javascript over an insecure connection and then solves it later with SSL/TLS (but he doesn't acknowledge that this is a valid solution). Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection. He talks about browser cache but says that ja…

I don't much like this article either, despite being its author, but I don't see how you've managed to refute its applicability to the application being discussed on the thread. The mutual exclusion referenced up thread is real.
Post reply on HN