https://technet.microsoft.com/en-us/library/dn520872.aspx

I believe the syntax is just

    Get-FileHash [file] -Algorithm SHA256

http://implbits.com/products/hashtab/

https://technet.microsoft.com/en-us/library/cc732443%28v=ws....

It says in the About section on the home page "Unless someone can intercept your local traffic and our traffic to a site, you'll be able to spot MITM attacks". I'd argue that this is not entirely true. If an attacker operating as a MITM can intercept all local traffic (e.g. via some form of DNS attack), they do not need to control the traffic from hash-archive.org to 3rd party sites. They simply need to control how hash-archive.org is presented to the victim. In theory, the attacker could serve up a bogus version of hash-archive.org that appears to be legitimate but is returning falsified hashes that match the malicious downloads they have intercepted elsewhere.

You might claim this is not possible because hash-archive.org runs over HTTPS so an attacker would also have to somehow generate a valid SSL certificate signed by a trusted CA. This is true but if someone types hash-archive.org into their browser URL bar, the initial request is made over HTTP. The legitimate hash-archive.org redirects the client to HTTPS seamlessly but a fraudulent hash-archive.org could just keep the victim on HTTP.

To provide some mitigation against this type of attack, you could do a couple things:

* Only allow hash-archive.org to be accessed over HTTPS (port 443). Close port 80. [EDIT: in fact, this doesn't really help all that much because the MITM can still try serve their bogus version of hash-archive.org over HTTP]

* Set the HTTP Strict Transport Security header (HSTS) [1]. After the first visit to the legitimate hash-archive.org, compliant browsers will only ever allow future visits to be made over HTTPS.

For good measure, you could also set up HTTP Public Key Pinning (HPKP). HPKP is a 'security feature that tells a web client to associate a specific cryptographic public key with a certain web server to prevent MITM attacks with forged certificates.' [2]

[1] https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_s...

[2] https://developer.mozilla.org/en/docs/Web/Security/Public_Ke...

One request: there are lots of users who would be well-served by a way to compute hashes in-browser via the WebCryptoAPI [1]. Would you consider accepting this feature into hash-archive? For users who aren't able to install or have difficulty using a hash calculator locally, this would enable verification of downloaded files in a one-stop online workflow.

[1] https://www.w3.org/TR/WebCryptoAPI/

edit: I stood up an instance here, and I'll make an effort to keep it running and updated: https://hash-archive.probablybroken.com/

Alternatively you would have to install a local helper process outside the browser, and at that point, you're basically an antivirus. In fact, I think AVs are the ones better placed to add this as a feature, as well as already having the significant resources needed to maintain a secure archive of hashes for files (although I had thought up a signature-based scheme that software vendors/distributors could adopt for a small fee).

There are some ways of doing it, depending on exactly what your threat model is, but I think it's risky in general. Right now this is just in the planning stages, but I want to have submitting URLs be a manual button click for each download, and also provide an option to use a local copy of the database (so that all lookups would be completely private).

I think there's also potential for better tooling, for example CLI tools that integrate with Hash Archive (or other sites/databases) directly.

  sha256sum -c <(curl -sS https://hash-archive.org/history/http://openwall.com/signatures/openwall-signatures.asc | sed -nr 's/.*sha256&#x2F;([a-f0-9]*).*/\1 openwall-signatures.asc/ p')