Cryp.sr Host-Proof Keyboard-Friendly List Manager

[Paul Keith]

I'm not really sure if what is making people twitter this is due to the service or the concept but I'll let mouser decide.

Personally, I think both are wonderful. The only flaw is the flaw with many online list managers, do you trust the longevity of the site and the memory capacity?

The in-built auto-generate password though is very nice. I think it can be a good medium between those that seek anonymity and those that seek to register but hate the e-mail confirmation thing.

Unfortunately there doesn't seem to be a free forum host that supports this feature.

Link: http://corte.si/posts/security/crypsr-evolution.html

A couple of months ago I launched cryp.sr - a minimal, proof-of-concept host-proof application that was little more than a text area with some crypto bolted to the back of it (more detail here). In the first few days after launch, nearly 1500 pads were created, and from the logs it looks like at least a few dozen people still use cryp.sr regularly today. This left me scratching my head somewhat - cryp.sr had no features at all, and its only redeeming quality was extreme simplicity. What exactly were people storing in their cryp.sr pads? Well, we can safely assume they weren't writing novels in a browser text area. In fact, we can take a pretty solid guess that most cryp.sr pads contain lists - most likely lists of login credentials and todo lists.

So, I thought, why not make cryp.sr a kick-ass host-proof list manager? I could give it all the things I've always missed in the innumerable online todo-lists I've tried: nested lists, VI-like keybindings, multi-level undo, Markdown for formatting. And that's exactly what I've done. Please try out the new cryp.sr, and let me know what you think. Since I'm now actually trying to make an app that users will find pleasant to use, I'm especially interested in feature requests and usability problems.

Definition of Host-Proof:

The goal of host-proof applications is simple: to design web applications in such a way that we don't have to trust the host. Data is encrypted and decrypted on the client-side, and the server only stores encrypted data. The server never sees encryption keys or cleartext data, and couldn't access the user's information even if it tried.

The host-proof idea is still in its infancy, but ultimately, we hope that host-proof techniques will let us combine the benefits of the cloud with strong, host-independent data security guarantees. The possibilities are incredibly enticing. We can imagine a cryptographic Facebook where you don't need to trust one company to aggregate the entire world's private data in the clear. We can imagine storing medical records and financial data in the cloud while still allowing people to maintain direct control over who uses the data and how. We can imagine a Gmail where everyone uses crypto by default, where decryption and encryption happens right in the browser. The technical obstacles that stand in the way of these dreams are immense, but if we can surmount them a better world lies beyond.

[mwb1100]

I haven't read all the details (I'm just going by the snippet you posted in your message), but the idea of a 'host-proof' application where don't have to trust the host seems fundamentally flawed.

The thing is that the application is provided by the host, so if you don't trust the host, you can't trust the application.

[Paul Keith]

Yes, it's fundamentally flawed but equally interesting from a future possibility way.

Take these concepts from the comments under Hacker News:

http://news.ycombinator.com/item?id=1226277

http://news.ycombinator.com/item?id=1227111

1 point by NateLawson 80 days ago | link

There's no such thing as "host proof". There is software tamper resistance, which gives limited protection against the host and is often used for DRM. But this software does not use software tamper resistance. The author made up the term "host proof" to refer to the fact that the data is not stored on the client and is sent to the server encrypted. That's it.

This is Javascript "pgp -c" (passphrase-based encryption) but less secure.

With Javascript crypto, you implicitly trust the server. You are executing code downloaded from the server in order to encrypt your data to upload to the same server (or one run by the same entity if not the exact same box).

Instead of trusting the server to encrypt your data for you, you're trusting it to send you unmodified, non-buggy code to encrypt your data for you. Every time you connect to it. The one time it sends you a trojaned (or buggy) version of the code, your data is compromised.

I prefer to get my software once, audit it, and be sure I'm running the same thing every time. With Javascript crypto, every time you connect to the site is a crapshoot. Is it 0wned today? Maybe.

The comments section of a post I wrote has a discussion of Clipperz, a JS crypto library:

http://rdist.root.org/2009/06/10/when-crypto-attacks-slides-...

http://news.ycombinator.com/item?id=1227304

He actually talks about that in the post, if you read it. He's making a Firefox plugin to validate JS before it's run, it's a bit down near the end.

http://news.ycombinator.com/item?id=1227397

It's incorrect that there is no such thing as host-proof assuming the meaning intended by cryp.sr, but you would be correct in being put off by a false sense of security this provides for users of the web based version of the interface.

I believe that's the point of the client library at http://github.com/cortesi/crypsr_client. The only things you're asked to trust is that encryption algorithm is good and that the host will delete the encrypted data long before the processor in your smart phone is fast enough to decrypt it in 30 milliseconds. If the host returns bad data, it simply won't decrypt and it will be trash.

The real problem with this service is that it's intended to be an easy to use secure means of sharing information from one to many, but to make true secure use of it everyone needs to download a dedicated trusted client and the problem becomes no different than it has always been and only marginally more user friendly than hosting the data yourself.

Refusing to trust or rely on SSL by using javascript based encryption is something I've experimented with a bit in the past. Without this you are still relying on SSL which only protects the information in transport anyway. If the server is compromised, then at the least all of the information already stored on the server is secure as each key is not on the server at all. At that point you just have to worry about whether the algorithm has flaws or if the person gaining unauthorized access has a couple supercomputer farms and many years on their hands.

It is true that if you rely on the host to provide you with the encryption algorithm then it is open to future compromise, but the data couldn't be retroactively compromised until the moment it's accessed again via a modified page. Due to this, using cryp.sr via a browser is less desirable than using the open source client until there's a trusted plugin or greasemonkey script.

or the checksum issue:

http://news.ycombinator.com/item?id=1227209

It'd be neat if there were signed or invariant web documents. Perhaps naming things as their own checksum? This way, if it were ever changed (...) the document name would change and the reference would break. The client could check at retrieval time if the checksum matches the label?