Cryp.sr - a minimal host-proof cryptographic textpad
corte.si
corte.si
I also informally discussed a number of features that a community would require so people could trust numerous hashes of compiled software.
Everything, it seems, ends up as a web app these days :)
It would be better to have a desktop application, with source code the user can verify. Then no matter what the host changes on their end, I can know that only the encrypted text is being sent. Even better, host-based applications can tie into existing frameworks like GNOME Keyring and GnuPG, for even better security than can be provided by a 128-byte passphrase.
This concept of "host-proof hosting" seems to encourage that we discard well-proven methods in favor of implementing new crypto schemes in the hostile browser-space.
Are web end-users really better equipped to ensure application security than web host administrators? </rhetorical>
It's early days, but I think that given published client-side source, enough users to provide vigorous peer review, and a verification mechanism like AppHash (which guards against exactly the kind of injection you talk about), it's possible to get it right.
What ever happened to all the other non-web-app crypto that has been doing much better for the past 20 years (PGP, SSL, /dev/urandom)? How does your solution compare to those?
As an aside, I would _love_ for browsers to expose a good, standardized set of crypto routines. They don't, so we do the only thing we can - implement them in Javascript. This makes me as queasy as anyone, but it's the best we can do at the moment.
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-...
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.
If you suspect such attacks, the only defense seems to be adding more hardware. For example, you could use the root of trust from a TPM module or the added physical security provided by a lockbox.
He does seem to be trusting twitter however (and twitter isn't host-proof). Spreading out or mirroring the discussion could give you a high confidence but I think you'd need something like PGP's chain of trust to be provably secure.
even better (from my pov) would be something that worked similarly, but used used a local cache and told you when pages changed. i imagine it would always warn on first change and then flag pages that always change as "insecure", pages that have changed just now as "hack attempt" and pages that are constant as "original". you could imagine browser bar colours that signal those...
this is the same kind of approach i think should be used with SSL certification (indicating when the CA changes for a particular page), which would help secure against the recent discussion of govts pressuring CAs to sign fake certs (and obviously isn't new - it's basically what ssh does).
[edit: hmm, although what page is completely constant? when my bank balance changes i don't want an error flagged. no idea how you solve that in general]
In comparison to this, a cipher that is both fast and also secure would be f.e. Blowfish, a 16-round cipher supporting 448-bit (56 bytes) keys, while still, on 448-bit keys, operating about 25% faster than the not quite as secure AES-128 does with its 128-bit (16 bytes) keys. Blowfish is entirely free of patents, whereas most of the cipher modes of AES are patented.
The second most important factor in a cipher's security is its keysize. If the cipher withstands all cryptoanalysis on its full amount of rounds, the last resort is brute force, and with brute force every extra bit of keysize matters to the feasibility and practical possibility of breaking the data. 128 bits of AES is today broken with modern parallel means in ridiculously short times (read: hours). Every extra bit of key theoretically (but not always practically) doubles the work required; a 129-bit key is twice as large as a 128-bit key; a 130-bit key is four times larger than a 128-bit key; a 448-bit key is 320 times larger than a 128-bit key.