[chadkeck]

Hey Thomas, The itch I was scratching with this tool is that there isn't a built-in way in Windows to get a digest of a file, so... what better way than doing it in the browser?

Also, I'm the paranoid type and don't like the idea of uploading a file to someone else's server if I want the digest.

[tptacek]

You aren't worried that doing this via Javascript will make it insecure for that use? In almost the same manner as uploading your file to a server (simply to get the hash) would be?

[chadkeck]

I dont' really understand what you're saying here. Other services that calculate the digest of a file online require you to upload your file to the service/site where you don't know what they will do with it. With Browser Hash, not one bit of your file leaves your computer or travels over the network.

[tptacek]

How do I know that my file is never leaving my computer? To verify that, I have to verify every line of Javascript code influencing that page, every time I use it, to make sure it isn't spiriting away my file contents or feeding bogus SHA fingerprint values back to me.

[xtacy]

I think he means that the JavaScript that computes the hash can be MITM'd.

[chadkeck]

Well I guess I'm not so paranoid if you're worried about the JS being MITM'd :D

[wccrawford]

How would it be MITM'd? It all happens on your computer. Nothing travels over the network after the page is downloaded.

[antimatter15]

I think what xtacy means by MITM is that the javascript sent by the server might be MITM'd and altered to return a different value than the actual hash.

But for instance, if I'm trying to SHA1 a Windows 8 iso (the kind which I imagine would be by far the most common use case - in which a cryptographically secure hash algorithm isn't even a prerequisite any checksum would do).

It's not any worse than downloading the sha1sum app from any http site.

[tptacek]

No, it's worse than downloading the "sha1sum" app, because you only have to download "sha1sum" once. You can use a variety of out-of-band methods to verify the file that you can't reasonably or cost-effectively do with a website.

A website is essentially "installed" every time you visit it.

[justinschuh]

Tom's point is that you're serving the JavaScript and HTML over HTTP. So, the entire site can be man-in-the-middled.

[Zash]

Quickly, someone, make an identical looking site that actually uploads whatever you drop on it! ;)

[Zash]

In this world where everything is done through a browser, where would I drop my files from?

On a serious note, can one drop an attachment from say gmail onto that?

And dear someone, please tell me that sha1sum & friends exists for Windows!

[chadkeck]

1. Haha, I agree that files will eventually become less accesible for the majority of computer users. Something like how the iPad handles projects/songs/documents instead of the generic "file".

2. Due to HTML5 limitations, you will need to drop the file from your local storage onto the browser window.

3. Yes you can get digests of a file on Windows, but it doesn't come with a built-in program.

[antimatter15]

There's a certain cool factor of file drag/drop but I think that the click-to-browse paradigm is useful on certain laptop trackpads where dragging isn't a pleasure and other situations. It would be nice if you made the drag area clickable (like min.us).

[thirsteh]

This could be useful to validate large files after downloading them, e.g. ISO files for Linux distributions--however that goes out the window with the 10MB size limit.

Why the limit? Does it take too long to compute hashes for larger files?

[chadkeck]

Absolutely agreed. It is due to the immaturity of the browser implementations, which will hopefully be fixed soon.

It regularly crashes(!) Chrome on "large" files; thus, the limitation.

[antimatter15]

You could split up the file chunks by reading in sections (blob.webkitSlice and mozSlice) as array buffers and sending them to a worker object. Then you could process those in chunks with WebWorkers (or WebGL) and have a progress indicator.