Just a small question: why reinventing wheel if HTTPS (TLS) client auth. with certificate already exists?

We can't just deploy HTTPS there, we need to make it work through HTTP.

Unless you're planning on repeating this for every http request, the session will be vulnerable to hijacking. How do you propose to deploy the key to the client?

No cryptography using client-side JavaScript can be secure without HTTPS. Any MITM attacker can send JavaScript that can do anything with the secrets the browser has access to, then there will be no secret.

@symcbean It was exchanged through a secure channel. And yes this is going to happen with every request.

@billc.cn What if it doesn't have the key?

@almosnow You said "3. The client has access to an input field where they load their key file." All an attacker have to do is to change the script and upload the file to the attacker's server.

@billc.cn Thank you, that's awesome, I haven't considered that.

@almosnow - I'm curious, why can't you deploy HTTPS? It sounds like you are trying to implement a network connection that maintains both integrity and authenticity, two things that SSL is really good at and that are really hard to implement without SSL.

@NeilSmithline Sure thing, some guys need to send data to my HQ, the information they send is not sensitive per se so I don't care if it goes in cleartext what I do care is to be absolutely certain that they are the ones providing the information on the other side (as well as which one of them is it). I know already that security experts love to repeat buzzwords here and there because they read it everywhere in magazines and blogsm but when these guys enter the real world (which may never happen, btw) they'll find out that it's not necessarily made of all the things they assume to be true.

Cont. well, since I'm deploying this to my clients here and there (most of them people who barely know how to turn on the computer and send me their data) I need to think of the easiest way to achieve this, from an user perspective. HTTP through port 80 over TCP/IP is the most widely deployed medium to exchange information that ever existed, so I'm going to take advantage of that. And yeah that's it. If you think of a better alternative for solving the overall problem, please let me know.

What will the client be? A custom client? A browser?

A web browser, easiest thing to deploy too, they already have one.

Web browsers support HTTPS, and providing a password to the clients would give exactly the same level of confidence that it is them on the other end. You are overcomplicating this, whilst ignoring simple, well tested, options.

@almosnow: "security experts love to repeat buzzwords here and there because they read it everywhere in magazines and blogs" - TLS/SSL/HTTPS are very well deployed in the real world, and are very much solving real problems. Every major HTTP server can handle HTTPS, and you can even get real server certificates for them now for free courtesy LetsEncrypt. Hell, you can even deploy HTTPS over port 80 if you absolutely have to for firewall or other reasons (example.com:80).

If you need to verify that the data was sent by the sender, but you don't care about the confidentiality of the data, and you're limited to plain HTTP, would it suit your purposes to have the sender sign the payload with GPG (or similar) before sending?

"security experts love to repeat buzzwords here and there because they read it everywhere in magazines and blogs" so why do you even bother asking?

Recommended read

If you have a problem, take it to Information Security Meta(meta.security.stackexchange.com). Don't put irrelevant content in your post.

So, web browser? Unless you depend on the users manually copying and pasting and running the crypto, you are already doomed.