c++ encrypt a text with a key received over packet? keyczar?

I'm storing a client's password in his device and there are times when clien开发者_运维问答ts need to send their password to server.

• When a client connects to me(server),
• I give him a key that will be used for encryption.
• I want a client to send a encrypted password by the key.
• Server will decrypt the password with the key(which was stored) and verify the password.

Even if it may not be perfect, it sounds more secure than using one static key stored in client and server.

Sounds simple enough and I was looking at c++ encryption library(crypto++), bleh looks too complicated.

Found there is a easy one to use. Keyczar.

But doesn't seem to offer the functionality that I need.

Keyczar seems to require to generate a file that will hold encryption key, and this file is generated by one of their tools, which will be too much hassle to do it on the fly.

If this can be done in c++ or keyczar(I may have missed what it can do)

please enlighten me how to.

Thank you.

Linux/Mac platform.

If you are sending the key to the user immediately before the user uses it to encrypt his or her password, you might as well be sending the password in the clear. (You're sending all the data required to reconstruct the cleartext password, anyway.)

A better method would use TLS to encrypt the entire conversation using a nonce-protected (to avoid replay attack) randomly generated session key.

If you really wanted to be fancy, you could use client-side x509 certificates to authenticate the client for you -- then you wouldn't need passwords on the server at all. (But you might still want to use the password to store the private key encrypted on the devices.)

If you like the idea but dislike TLS because x509 is supremely complicated, perhaps it would be easier to integrate ssh session management, using ssh keys. ssh keys are far easier to work with than x509 keys, but their simplicity means they aren't applicable everywhere.

if the key exchange is not secured, you'll gain absolutely nothing (except reduced replay attack); perhaps simply look into TLS/SSL for the purpose of securing the transport