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

Trsst: a distributed secure blog platform for the open web

kickstarter.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Trsst: a distributed secure blog platform for the open web

#31

Post by mpowers »

tptacek wrote: post #23
mpowers wrote: post #14

Earlier quoted context omitted.

If normal people are going to use it, it has to run in a browser, hence JS. There are working open source crypto libs in JS today, and kind of the nice thing about them is that they're not compiled, so (if unobfuscated) you can literally just inspect the source. That said, we plan to generate keys like bitcoin does, so there if you have a bitcoin library in your language of choice, that part is done. The server code…

No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not: * If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different. * Even if your users are sophisticated, they effectively have to install the code every time they use it , so any inspection they did yesterday will help them not-at-all today * Browser Java…

If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.

Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends.

I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to let you do so.

Let me be clear that JS is not required; it's just how we're making our reference client because we don't believe most people are going to download a custom client.

You can write a working client with bash+openSSL+curl if you want. The whole thing is simply signed text snippets over http.

Re: Trsst: a distributed secure blog platform for the open web

#32

Post by yapcguy »

mpowers wrote: post #8
krcz wrote: post #5

What programming language do you plan to use for the reference implementation?

JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.

Why do you need Kickstarter for this?

Why don't you build it first and if it gets popular then ask for donations?

What about the open source projects you're building on top of? Are you going to give any of those programmers some money?

> Yes. We're starting with the critical bit - the client - out in the open in JS w/ off-the-shelf open-source. Needs many eyes.

Frankly, I'm sick of people jumping on the "open-source" bandwagon and diverting resources from those who truly deserve it or who have a track record in the field they are asking funds for.

You know, people like Stallman and Torvalds took risk and bore the opportunity cost of spending time to build things they believed in and had passion for.

It seems too many of todays entrepreneurs are afraid of taking risk and want to pass it onto the public. I especially dislike what App.net did, conning people into giving money to build a closed source platform and then selling part of that company to venture capitalists.

Re: Trsst: a distributed secure blog platform for the open web

#33

Post by pyre »

mpowers wrote: post #26
newman314 wrote: post #18

Earlier quoted context omitted.

Read "JavaScript Crypto considered harmful" http://www.matasano.com/articles/javascript-cryptography/

Gah, HN is rate-limiting my responses. Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point…

Assume for a moment that JS crypto is insecure. If you use a web client with JS crypto to bootstrap acceptance, then the majority of your clients will end up using JS crypto. If the majority of the clients on the 'network' are insecure, then what's really the point?

Re: Trsst: a distributed secure blog platform for the open web

#34

Post by mpowers »

Grue3 wrote: post #24
mpowers wrote: post #8

Earlier quoted context omitted.

JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.

Likely? So you don't even have a solid plan how to build your app?

Well, it's kickstarter so we're deferring some decisions until it closes, and leaving room to listen to our backers.

I know you probably meant to snark, but to take your question seriously, the question we have is: do we open up our working prototype, or write a reference impl from scratch in a language more useful to our community.

Re: Trsst: a distributed secure blog platform for the open web

#36

Post by mpowers »

skore wrote: post #22
mpowers wrote: post #11

Earlier quoted context omitted.

Our use cases are of Twitter too, so it makes a certain sense. We haven't designed the UX yet, but it's meant to convey the idea. That said, the architecture supports not only Twitter but FB-style friending and private group shares; we want to encourage different clients in different form factors, with the advantage being that they'd all interop. No more siloes.

Yeah, sorry, all of that is irrelevant. You use somebody elses UI on your kickstarter. That is a terrible, terrible idea. It's an idea terrible enough that it will make people doubt your competence. For me, personally, "building strong crypto" and "lifting the twitter UI because too lazy to whip up some visualization of a simple roadmap" don't go together.

Agree, I yield. It's gone now.

Re: Trsst: a distributed secure blog platform for the open web

#37

Post by walid »

yapcguy wrote: post #32
mpowers wrote: post #8

Earlier quoted context omitted.

JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.

Why do you need Kickstarter for this? Why don't you build it first and if it gets popular then ask for donations? What about the open source projects you're building on top of? Are you going to give any of those programmers some money? > Yes. We're starting with the critical bit - the client - out in the open in JS w/ off-the-shelf open-source. Needs many eyes. Frankly, I'm sick of people jumping on the "open-source"…

> Frankly, I'm sick of people jumping on the "open-source" bandwagon and diverting resources from those who truly deserve it

Is there a list of deserving people that gets curated by someone? I think that those who deserve are those that get support because what is being advertised is what people will pay for if they want it.

On the same note as those who truly deserve it I think that there are so many ideas and open source is not about a list of people but about whatever you want or need. Pushing back on new ideas is not necessarily the right thing to do. Vote with your money; support if you like something and walk away if you don't.

Re: Trsst: a distributed secure blog platform for the open web

#39

Post by tptacek »

mpowers wrote: post #31
tptacek wrote: post #23

Earlier quoted context omitted.

No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not: * If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different. * Even if your users are sophisticated, they effectively have to install the code every time they use it , so any inspection they did yesterday will help them not-at-all today * Browser Java…

If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends. I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to le…

I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea?

Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.

Re: Trsst: a distributed secure blog platform for the open web

#40

Post by timtadh »

mpowers wrote: post #31
tptacek wrote: post #23

Earlier quoted context omitted.

No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not: * If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different. * Even if your users are sophisticated, they effectively have to install the code every time they use it , so any inspection they did yesterday will help them not-at-all today * Browser Java…

If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends. I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to le…

> If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.

It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an externally loaded resource embedded on the page that resource may modify the execution of your crypto. There are also CSFR, XSS and other JS vulnerabilities to account for.

Javascript is a hopelessly bad place to do crypto. Consider doing an signed browser extension that does this on the desktop and native apps on the phone. I would also suggest a native app on the desktop as well. People seem to really like them for twitter.

Post reply on HN