0

I need to build a project for uni where I need to transfer data securely from a client to a server. I can't use PKI structures and can't save pre-shared secrets (Imagine travelling to china and some bad guys check your pc). The only secret is the client's password, which got salted, hashed and saved into the database of the server.

So I thought about this: Generate the hash on the client pc. Generate a key from this (using pdkf2) on the pc as well on the server. This key is now the symmetric key. The client encrypts a specific, non secret phrase and sends to the server, who decrypts it and checks if its the "expected" phrase. If yes, the client is now authenticated. This happens a second time, just the other way around. So now both know the other one is not faked. Then, the client can encrypt the data, send it to the server who can decrypt the data.

Is this really secure? How can I be sure that after inital "handshake", they are still the same? If this is a bad idea, how would you solve this problem?

Please note, that I'm really new to this. Thank you

7
  • "Generate the hash on the client pc." - How? The client would need to know the salt in order to create the same hash as the server has. In general: if you use your own algorithm instead be using existing ones you better get advice from experts in cryptography. You'll find these at Cryptography. Apr 22 '20 at 5:29
  • @SteffenUllrich Yes, I would have the salt on the client pc. It could be sniffed but I thought it's just for blocking Rainbow Table attacks. I can use existing mechanisms, but I couldn't find one which fits here. How would you solve this problem? Apr 22 '20 at 15:57
  • "How would you solve this problem?" - since I'm not a crypto expert I would try to rely on as much established methods as possible and would not invent my own. For key exchange there is Diffie-Hellmann but this needs proper authentication. Given that both client and server can derive the same password hash this might be taken as a shared secret and thus PSK based authentication could be used. But again, better ask at Cryptography. Apr 22 '20 at 16:27
  • @SteffenUllrich I posted the answer before the question was updated. I can't use PKI structures... Otherwise, I would have seen it.
    – Aviv Lo
    Apr 22 '20 at 16:57
  • @AvivLo: Since you've removed your comment I've removed mine too. Apr 22 '20 at 17:04
1

It sounds like the solution that you are looking for might be PAKE or SRP. With PAKE/SRP, the server stores a salted hash of the password, and the client demonstrates to the server that it knows the password, without the client ever sending the plaintext password (or password-equivalent data) to the server. At the end of the process, the client and the server share a shared secret.

See https://blog.1password.com/developers-how-we-use-srp-and-you-can-too/ for more info.

1

Let me first say, cryptography is hard and I highly recommend you do not attempt to invent a novel crypto system.

With that said, it seems you are interested in some form of ephemeral diffie-hellman key exchange.

Edit As pointed out in the comments, my initial answer was not thorough enough to be helpful

I need to build a project for uni where I need to transfer data securely from a client to a server

If this is an academic project, and you assignment is to design a novel cryptosystem then you may want to go the the crypto stack exchange site. But if you are doing this to secure something out in the wild, my statement still stands, do not invent a novel cryptosystem.

I need to transfer data securely from a client to a server. I can't use PKI structures and can't save pre-shared secrets (Imagine travelling to china and some bad guys check your pc). The only secret is the client's password, which got salted, hashed and saved into the database of the server.

You may want to assess this requirement and ask yourself or the person you are implementing this for: How do the client and the server know they are communicating with the correct entity? Anything you do without this assurance is not technically secure. This is why PKI exists.

Maybe your assignment is to implement something that builds on top of the Web of trust model. Something like Pretty Good Privacy (PGP) where the client initiates communication with the server using the public key of the server (which is technically not a secret). Even this is built on the assumption that the private key doesn't get into the hands of the wrong person.

Is this really secure? How can I be sure that after inital "handshake", they are still the same?

You would have to ask someone who is an expert in cryptography, but I would say doing this step "Generate the hash on the client pc. Generate a key from this (using pdkf2) on the pc as well on the server. This key is now the symmetric key." without first preventing a MitM attack will break the security of the rest of the system.

5
  • I actually thought that this is just a way it's done anyway. But I will look deeper into Diffie Hellmann. Apr 21 '20 at 21:14
  • Diffie-Hellman alone would not be enough here since it does not authenticate the server in any way. This means the client does not know that it exchanged the key with the intended server but it might instead be exchanged with some man in the middle attacker. Apr 22 '20 at 5:08
  • @SteffenUllrich That is true, getting over the mutual auth hurdle is no small task if the constraint is that the client system cannot carry anything with it. I didn't have a solution for that, as anything I could think of would be more of a hack. That said, I did want to give a clear recommendation not to invent an ad hoc crypto system. I can edit my answer to remove the Diffie-hellman recommendation if you think it is misleading.
    – iraleigh
    Apr 22 '20 at 18:15
  • "I did want to give a clear recommendation not to invent an ad hoc crypto system" - I fully agree with this but this by itself should only be a comment since it does not actually help to solve the problem. Apr 22 '20 at 18:23
  • @SteffenUllrich thanks for the feedback, I deleted the answer initially because I agree that my answer was not helpful and I didn't want to mislead anyone. I went back and added some more material
    – iraleigh
    Apr 24 '20 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.