Hi Francisco. I split this off into a new thread, since it touches on some points on why the security model for Passlok is broken.
Comments inline... On Tue, Aug 13, 2013 at 2:54 PM, Francisco Ruiz <[email protected]> wrote: > > 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. > No, there are other Unicode characters in the document, e.g. U+25BC. Manually removing these characters isn't going to help you. I changed my browser's default encoding. That changes the charset in the html tag, as well as some characters in the body. I tried UTF-8, Arabic, and Chinese encodings and they all saved with slightly different data, which will all fail to verify with your single hash value. Chrome ships with like 30 different supported encodings and each browser may handle this differently, so there are many potential hash values from your page. 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. > If users have to trust the code that is served every time they visit Passlok, then users have to trust you and your hosting provider Site44 entirely. If Site44 were compromised or subpoenaed, you may not even know about it. You suggested users download the Passlok page, validate it themselves, and run their local copy. Now you say that nobody is going to bother, which means we're back to the security model of trusting you and your hosting provider entirely. > 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. > You admit you don't understanding what's going on with the encoding, but decided to intentionally corrupt an encoded key value because you didn't like a string looking non-random? The consequence is that you added unnecessary code complexity to fix the key value every time you want to use it. Did you change any other part of the crypto implementation based on aesthetics?
-- 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].
