Hacker News new | past | comments | ask | show | jobs | submit login

> We are building the first fully-conforming trsst server, plus an open source web client including javascript libraries for core functionality like the cryptographic functions.

Wait, wat?

From the first glance it looks like they just patched buzz words together and decided to call it bitcoin-like decentralized syndication network on a PKI

What about anonymity? Anyone who has the whole signing chain could track down the author. The anonymity of bitcoin is achieved by mixing hubs[1], you can't split a blog post in half and mix it.

[1]: https://en.bitcoin.it/wiki/Anonymity

btw what happened to Open Source today? You have to hype on Kickstarter and waiting for people throwing money at you in order to start coding?




>you can't split a blog post in half and mix it.

Hmmm. You must have never used Twitter.


Honestly, I think it is worth skipping cryptographic anonymity for doable now.

If you want anonymity, post from an Internet cafe on a laptop you bought for cash on Craiglist.


is there any internet cafe that allows you to reach the open web without asking you for identification first?


Starbucks is everywhere and only requires that you accept their TOS.


And they save your MAC address to their database.


Anyone planning to leak sensitive documents likely already knows how to change their mac address


But it's not like you can't change that...


Never found one that does ask for ID. Is that your point?


Here where I live the wide majority of cafes (and other hotspots) rely internet access service to telcos which require you to fill in a form on their website identifying yourself before you hit the web. That's why I asked. Nice to know you can browse around anonymously in Starbucks though.


All those I've seen (mostly abroad where I've used wireless in restaurants, airports, etc) allow you to use fake details. I've never registered with true information to use public wireless.


That is really great for you. Here there is not such thing. Go anywhere with public wireless, a hotspot or whatever, connect to their network and try to browse around. Bing, "please choose one of our plans: per hour, day, week or month". Type in your credit card number and you are "free" to go. Of course, you can try a stolen ID and/or credit card combination, but then you are at your own risk.


I'm not exactly fond of Bitmessage. But in this case, it seems much better alternative.


> javascript libraries for core functionality like the cryptographic functions.

Clientside JS for crypto? No. Bad idea.

http://www.matasano.com/articles/javascript-cryptography/

Their reasons:

> Secure delivery of Javascript to browsers is a chicken-egg problem.

> Browser Javascript is hostile to cryptography.

> The "view-source" transparency of Javascript is illusory.

> Until those problems are fixed, Javascript isn't a serious crypto research environment, and suffers for it.


I spent some time working on a project to create an encrypted contact form for people to use on websites. Thought it might make for a good wordpress plugin, but I was wrong.

Having gone from a position of "why not" to "oh hell no" on javascript crypto, the fundamental problems as I see them (aside from the ones outlined in your comment):

* Each javascript engine is different, with different (or sometimes no) sources of differing (or no) levels of randomness, which is essential for crypto to work.

* Most browsers support some level of javascript introspection whether you like it or not. Sure, things like Content Security Policies can be used to limit access from other tabs or domains but it's not just secure delivery to browsers that's a problem with javascript, it's execution integrity too.

* Most of the Javascript crypto libraries I've seen are ports of C libraries using tools such as llvm. As such they were not designed with javascript's functionality in mind, and as such are unlikely to have been anywhere near as scrutinised for side channel leaks as something built from the ground up.

The final nail in the coffin for my project was the fact that I'm not supporting a set of browsers, I'm supporting a set of ecosystems. Anything from plugins and extensions to minor version changes can affect the behaviour of a javascript engine in an unexpected way with potentially dangerous outcomes. I couldn't in good faith release a tool that lets grandma contact you without having to install PGP but in reality may mean she gets black bagged regardless because she used a dodgy tablet with no randomness source.


There are some relevant considerations in that document but I found it to be very dismissive. SSL for example is not hard to implement, and going ssl-always is now quite common.

Don't get me wrong, I certainly don't want to advocate slapping some crypto lib onto a site with a bunch of marketing script. A project from scratch with these considerations might some day get it done.


For now, crypto should be done via a native client. In the case of encrypted p2p communication, clients such as http://retroshare.sourceforge.net/ get the job done nicely.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: