Or cached locally, but I see your point and i agree that there is no ideal solution which exists right now. I think some of these problems (verifying checksums at every delivery) are likely simple problems to solve with browser plugins or trusted authenticating proxy servers.

I also completely agree with you that as OSS moves further into the mainstream, we’re going to start seeing these types of oversights coming to light. I think it was less than a month ago they realized that *OpenSSL* had a serious flaw in its PRNG. I guess this is a value judgment, but my opinion is that I would rather take my chances on the OSS community than on a proprietary vendor; I don’t see how closing a project’s source code makes the project *more* secure, if anything it seems like a disincentive to the developer to invest in substantial security reviews.

I’ve proposed this elsewhere before, I think the OSS community could benefit greatly from a centralized organization similar to SourceForge or FreshMeat dedicated to tracking software packages and hosting code reviews. Some type of system where reviewers or organizations sign checksums to attest that they have looked over the code and not found any potential problems. Reviewers could be volunteers or be paid by patronage. Users could then decide which reviewers they choose to trust (or at least see who has reviewed a package they’re interested in). Such a system would require little to no trust in service/application providers (especially in Host-Proof-Hosting scenarios). I guess everyone has a bright idea about this though…

@sullof
“Most people don’t use TOR… I would like to see an international regulation of the matter”

That would be nice, but I’m not going to hold my breath. Regardless, without a TOR-like system, I don’t see any possible way for a client-server paradigm to operate without IP addresses. Maybe that’s your point.

Thanks for the responses guys – this is a really interesting topic to me.

Most people don’t use TOR. Not because they are not paranoid, but because they don’t realize that the IP address can identify them.

I would like to see an international regulation of the matter. Europe, perhaps, will move towards something useful asking that IP need to be treated as personal information – http://tinyurl.com/ys698v

…it is absolutely necessary to establish some distributed framework for code review and authentication.

I agree, and would love for that to happen. But in order to accomplish this the delivery would need to be checked at every delivery of the code. That’s where the call for a “better browser” came into play with the recent Clipperz/Stallman call to action. It’s not immediately practical. But I wonder if there could be other ways to solve the issue that don’t require building a new browser.

they can trust the thousands of eyeballs reviewing the code on their behalf.

In theory yes. I just finished reading a post by Savio Rodrigues where he hits on this topic. He examines the case of a Springwise security flaw, and raises the question:

Two key benefits of OSS are the ability to read and understand the code we use and that “many eyes scouring the code” makes the product more secure.

Considering the millions of downloads of the Spring Framework, should we have expected someone to discover these security holes earlier? Or do developers use what the next guy/gal is using, trusting that “someone” has done the due diligence?

It’s a valid question.

2) “To understand if the process is correctly implemented, you need only analyze the client-side Javascript code.”

Technically, i agree that this is true. Unfortunately in actual practice it is unlikely that users will be capable or willing to inspect the javascript of the client code each time they use a site. This means that either the user must trust the application provider (as suggested earlier) or the user must trust some 3rd party’s analysis of the codebase.

If the user is forced to trust the provider, i don’t see what the point of all the encryption is. In this security model the only role encryption plays is to secure the data on the provider’s servers in case the servers are compromised. There is still NO guarantee that the provider won’t quietly change their code to forward decryption keys. In other words, this Host-proof-hosting paradigm only works (in a pragmatic sense) if there is some way of publishing 3rd party code review and verifying that the downloaded code matches the reviewed code.

“If you trust an application, by default you are trusting the providers behind it.”

Partially. The reason open-source cryptography and security software is preferred is that it can be peer-reviewed. This means that users are not forced to trust *only* the application provider; they can trust the thousands of eyeballs reviewing the code on their behalf. The problem of verifiable 3rd-party review applies to this example as well, and is a problem that could use adressing.

3) “By loading only the necessary code on-demand, we can optimize the user experience and overall speed of the application. ”

I don’t see that this is in conflict with the idea of preventing code changes, so long as the initial download contains checksums for any additional code which is downloaded. Again, this is an issue of ensuring that the code running client-side can be reviewed and users can have some confidence that if the code they download matches *some* checksum, that the application works as it is intended to.

4) “But… I connect to Clipperz and am greeted with a box that tells me I am connected from Rome, and a week ago I connected from Milan, etc.”

From what I can tell, Clipperz usernames are hashed before being sent to the server, so all the server knows is access times, the amount of data downloaded and the IP it was sent to. I can’t imagine any client-server model that had access to less data. The argument that IP addresses can be used to idenitfy user’s location ignores the fact that *really* paranoid users can use TOR and eliminate any relationship between their IP and their actual location.

In conclusion, I think that it is absolutely necessary to establish some distributed framework for code review and authentication. This extends to package managers for OS’s as well, as they are susceptible to many of the same exploits Passpack is. You’re right that it’s dangerous to view technology as a panacea, but technology can be used to enable communities to work together.

What about more general data privacy implications?

Standard (non-HPH) systems maintain a database of users’ data, that data can be accessed, viewed or indexed at anytime — as a normal procedure.

With HPH, that is exponentially harder to do, especially en-masse operations like data mining, and would likely require some sort of illegal action.

So while HPH may not be the silver bullet for all privacy woes, I think it’s an excellent starting point.

Ideas?

http://code.google.com/p/passpack/

Did you have a specific project in mind?

The algorithm used by Passpack to estimate the entropy of a key is based on Keepass quality measurer. Keepass is a great password manager. It is open source and there is an entire community devoted to its development. So I “trust” their approach to entropy estimation.

Shannon’s approach assumes a character base of 27 and the use of the English language only. NIST, extended the character base assumption to 94 characters, but maintains the English language assumption. Passpack allows the full range of the Unicode character set (about 100,000 characters) and is used by people of many different languages.

So suppose that a hacker (internal, i.e. the “bad employee” you like a lot, or external) obtains encrypted data, he can not know if the user chose a key in English, in Chinese, in Arabic or some other UTF8 lingual mash-up.

Vice versa, to defend against a hacker that knows the target user’s language, to obtain an effective quality measure we would need to adapt the algorithm to the user’s preferred language, choosing a different base sets of chars. It is clear that if an English speaking person uses Chinese chars a dictionary attack becomes very hard, but if a Chinese person uses Chinese chars… it’s normal.

So it is necessary an approach that don’t consider a specific language as reference to calculate the entropy, but a more generic approach… or in an ideal world, an algorithm that is contextualized on the single user.

I think that Keepass’ approach is a good base, so I chose it for Passpack. Other systems can chose other algorithms.

But this is not the central point of the discussion. Dictionary attacks are not exclusive to HPH – they are common to all systems including stand-alone apps and operating systems.

Suppose that there are two systems, A and B, that implements the same level of security, they are audited by the same security authority, they use the same connection provider, etc. All of their assets are identical, but System A provides a HPH application and System B does not.

Do you think that this makes a difference, or no?

I have managed both HPH and standard systems, so I know that the answer is yes.

The first thing I’ve thought is: is it possible to develop an “host-proof application framework” to build applications on it?
Maybe something like that could help spreading those concepts.

I mean… “Rails” was the internal framework of Basecamp… could “Proof” be the internal framework of Passpack? ;)

reference: Table A.1 of

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf