Hi Steve. I want to thank you for taking your time to help me. Your comments are awesome. May I follow up with some short questions, right after some of your comments?
Many thanks in advance. On Mon, Aug 12, 2013 at 7:18 PM, Steve Weis <[email protected]> wrote: > 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. > I think the Unicode characters got in when I added the qr.js code, which had comments in Korean ;-) Do you think it's maybe best to get rid of anything that is not strict ASCII? The code doesn't need any special characters. > 2. Relative link re-writing: wget returned relative links. Chrome replaced > them with absolute links, so that links work locally. > I've toyed with the idea of making absolute the couple relative links in there: the png for making a mobil icon, and the help page. Maybe it's better if they are absolute so the browser doesn't change them, uh? > 3. Whitespace: Chrome stripped out some whitespace. > I've tried to make super-sure that the code has no leading and no trailing spaces or linefeeds, so maybe wget is adding spaces? 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. > I've spent a lot of time making the code run nice and polishing the user interface. I didn't suspect code validation was going to be this difficult. Truth is, most users are never going to bother with validating the code, but a few will care intensely about this. > > 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'. > Ah, you saw that. It's the elliptic curve output. SJCL handles points and exponents as complex recursive objects. In order to display them for the user, I extract the data and convert it into base64. For reasons that I don't fully understand (probably having to do with 521, the true bit length of the elliptic curve numbers, not being divisible by 6), those strings always start with "A". Since I intensely dislike displaying supposedly random-looking strings that always begin with the same character, I strip it, but instruct the functions that read those strings from the interface to add it again before they do any calculations. Thanks again, Steve! > > On Sun, Aug 11, 2013 at 7:37 PM, Francisco Ruiz <[email protected]> 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 > [email protected]. > -- Francisco Ruiz Associate Professor MMAE department Illinois Institute of Technology PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok get the PassLok privacy app at: http://passlok.com
-- 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 [email protected].
