Francisco, you assume that all browsers will save a static version of the page identically. This is not the case.
I ran a test using 'wget https://passlok.site44.com' and Chrome's "Save As". The former will actually match the hash value you've posted, but the latter does not. I spotted at least 5 differences in Chrome's saved output: 1. Unicode: wget returned escaped Unicode characters. Chrome saved output containing actual Unicode characters. Your suggested method of cutting from view-source and pasting into a text editor may be unpredictable, and dependent on a user's OS and locale. 2. Relative link re-writing: wget returned relative links. Chrome replaced them with absolute links, so that links work locally. 3. Whitespace: Chrome stripped out some whitespace. 4. Style rewriting: Chrome replaced some style elements like "background-color: #FFA0A0" with "rgb(230, 255, 230);". 5. Chrome extensions: I have locally installed extensions that modify page contents, e.g. AdBlock and DoNotTrackMe. My locally saved copy of Passlok had elements that were injected into it by some extensions. Any of these will break your manual hash validation. These are specific to my version of Chrome, but other browsers may alter saved content similarly. To work, you must assume that your user has a local client (say wget or curl) that can save a canonical copy of your page without modification. Browsers do not guarantee this. Then you must assume the user has a locally installed tool to compute the hash, like sha256sum or openssl. Then they would need to point their browser at the locally downloaded file to actually use it. If you depend on locally installed software outside the browser and use local storage, the user is better off just using locally installed software to do the crypto. PS - I noticed some oddness glancing through the source. For example, the makepub() function strips 6 bits of a Base64-encoded leading 0 for no apparent reason. The rest of the code has to remember to keep adding back in the missing Base64 character or else it will break. The only reason I can think of someone doing this is because they didn't understand why the randomly generated Base64 value always started with 'A'. On Sun, Aug 11, 2013 at 7:37 PM, Francisco Ruiz <r...@iit.edu> wrote: > I still have to read through the references you supply, but I can already > see a misconception. They refer to the dangers of carrying out cryptography > with javascript-containing dynamic pages. My previous posting referred to > _perfectly static_ pages, which are supposed to be always the same coming > from the server, not modified by the browser in any way, and which, in > fact, you can save and store somewhere safe and never again have to get > from the server. I believe the intrinsic security of this kind of > javascript code is no different from that of compiled code, which also > should be checked for tampering, so long as it uses standard functions that > are not likely to be modified in browser updates. Sorry about the confusion. > >
-- Liberationtech is a public list whose archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
