

Cryp.sr - a minimal host-proof cryptographic textpad - giu
http://corte.si/posts/security/crypsr.html

======
hugothefrog
I've not heard the phrase 'host-proof' before, but I wrote my thesis on
trusted computing platforms
([http://www.cs.auckland.ac.nz/~cthombor/Students/mbarrett/mba...](http://www.cs.auckland.ac.nz/~cthombor/Students/mbarrett/mbarrettThesis.htm)).
Some of the work I review in it was related to proving a remote host to be
trust worthy, which seems to be of some relevance here.

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 :)

~~~
NateLawson
It's not trusted computing. It's "encrypted on the client by code downloaded
from the server before sending it back to the server".

------
jmillikin
An untrusted host seems like exactly the _wrong_ case for web applications.
What's to stop the host from adding in some key-logging Javascript? If it's
cleverly hidden, or inserted only for certain IPs, chances are low that
anybody would notice. Then the host would have your encrypted text _and_
passphrase.

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.

~~~
cortesi
The point is that all hosts should be "untrusted", because no host is 100%
secure, and no host is controlled by a 100% trustworthy entity. This fact is
inconvenient, so it's pretty much ignored in the current generation of web
applications. Host-proof app developers don't say that their hosts are somehow
less _trustworthy_ - we recognize that all hosts, including our own, are
untrustworthy, and try to design applications that take this into account.

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.

~~~
NateLawson
I read that as: "current web app designs are bad, and this is no worse." But
that assumes we can only choose your JS crypto or other bad web app designs, a
false alternative. There is a third option.

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?

~~~
cortesi
These things are entirely orthogonal. The "host-proof" paradigm is
specifically a web application design paradigm - the question we're asking is
"how can we do web apps better". Unless you're able to convince your mom to
interact with Facebook using PGP, it's just not relevant to this discussion.

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.

------
NateLawson
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://rdist.root.org/2009/06/10/when-crypto-attacks-slides-
posted/#comments)

~~~
m_eiman
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.

------
joshu
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?

------
stcredzero
Uses whitebox encryption techniques? I don't think so, since he doesn't
mention the term, and since he's using the jsCrypto library. I'm not sure one
can implement whitebox encryption in a VM language without calling out to a
DLL.

~~~
tptacek
It's not using white box crypto. You can implement white box (painfully) in
Javascript - white box is a transformation of the algorithm itself, not simply
an implementation trick.

~~~
stcredzero
Are there Javascript obfuscators/transformers that implement this?

~~~
tptacek
Not that I've seen, but again, the concept is algorithmic; nothing precludes
it from being implemented in Javascript. The whole idea behind WBC is that you
don't trust the implementation environment.

------
giu
Clickable: <http://cryp.sr>

------
daeken
It seems that this could be vulnerable to the Evil Maid problem. Can someone
that's more knowledgeable than myself shine some light on this?

~~~
tyleroderkirk
Most software-based security systems assume that the hardware hasn't been
maliciously tampered with. cryp.sr is apparently no exception.

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.

------
andrewcooke
interesting. so is something like abine host proof? <http://www.getabine.com/>
(i found them via here, but haven't used them). they seem to store the data on
the client, but i guess that still requires that you trust their code, so it's
not host proof? but then isn't that true of cryp.sr too?

~~~
glymor
The part from AppHash on covers verifying the downloading code matches the
externally released / peer reviewed version.

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.

~~~
andrewcooke
oo, interesting - sorry, i didn't read that far.

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]

~~~
cortesi
AppHash tries to address this by having something called a "hostile block" in
a page. The hash is checked for everything BUT the hostile block, and the
hostile block itself is checked to make sure it only contains static variable
assignments. Yes, this is a fiddly bit of code - I'd love for people to see if
they could break it.

------
hackermom
This is a really great idea. My only gripe is that it uses AES (due to that
being the only cipher in jsCrypto).

~~~
PostOnce
Just curious, what's your objection to AES?

~~~
hackermom
jSCrypto uses AES-128 only, a 10-round cipher with a small keysize, to which
there are a number of side-channel attacks available. AES is also a very slow
performer due to its computationally demanding nature, and still it does not
supply additional benefits from the large amount of work it puts into
scrambling data - a perfect example of another case of this would be the good
old DES standards, with its measly 56-bit (7 bytes) keys, which are
computationally more demanding than newer, safer ciphers, yet still so easily
broken.

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.

~~~
PostOnce
Informative. Thanks for taking the time to reply.

