On Tue, Dec 21, 2010 at 2:58 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > Notice that all three of the OP's use-cases were based on checksumming > files. I don't know how reading in a Blob and then hashing it would > compare to just hashing an equivalent string, but I suspect it would > have a decent perf hit. This seems like a pretty useful ability in > general, enough so that it's probably worthwhile to build it in > directly as a Blob.checksum() function or something.
I wouldn't expect a big performance hit from that. Start reading the next block (say, 1MB at a time) asynchronously, run the SHA1 for the previous block while that's running, and repeat. (I'd do the whole thing in a worker thread, so the synchronous SHA1 call itself wouldn't bog down the UI.) I'm not up on the internals of the file API implementations, but it seems like that should be pretty efficient. (Even the async requests should be unnecessary, since the OS should be doing read-ahead anyway.) > I still think it may be useful for the security use-case as well, > where you explicitly want a slow hash to begin with. If JS imposes a > slowdown on top of that, it could render a good hash too slow to > actually use in practice. Plus, you have to depend on the hash > implementation you pulled off the web or hacked together yourself, > which you probably didn't manually verify before starting to use. I had to think pretty hard to come up with a use case for something like bcrypt in Javascript, and the only one I've come up with seems somewhat flimsy: Sites could avoid ever sending passwords from the client to the server. Instead of sending a password directly, the server sends the salt for the user's password (or a random salt for a new password); the client sends the password hashed with that salt. This means that sniffing the traffic--even on the server itself where you might in underneith HTTPS--couldn't record a large log of user passwords to be used elsewhere; the server would never know the password to begin with, not even when the user first sets his password. The flimsy part is it depends on the Javascript doing the hashing being secure; if the server is compromised, the script itself could just be replaced. That's still potentially a win, because that's harder to hide--the backdoored authentication code now has to stash the unencrypted password in the request somewhere, rather than being done in the server where it's completely invisible to users. Did you have any particular uses in mind? -- Glenn Maynard
