Well, I can't see anything to prevent a man-in-the-middle attack. OK, your client knows that the "right" server is in the communication somewhere, but he does not know that to be the only party he is communicating with. I respectfully suggest this sort of question is better suited to a general cryptography discussion group than Crypto+ +. Let me pose another way of looking at the problem. There will be middlemen to your communication anyway (e.g. an ethernet switch, your client's network hardware, your OS's TCP/IP library). Forget about trust, and wonder what is the difference from a middleman "attacking" to just passing on your communications like a good middleman? It's about whether the middleman "understands" what is going on, and can use that information somehow.
What stops your ethernet switch from understanding, capturing, and replaying the password hash? On Aug 18, 6:33 am, Oleg <[EMAIL PROTECTED]> wrote: > Thank you for your answers. Could you verify the following scenario: > > We generate pair of keys: private and public, for example using RSA. > After that we incorporate public key to client application and private > to server. If client wants to login, it calculate hash of password and > send it to server. Server verify this hash with one that he has in > database. If hashes are equal, authentication successfull. After that > client send to server random generated text. Server sign this text > using his private key and send it back to client. Client verify > signature using public key. If everything is right, client "knows" > that he talks with "right" server. After that server and client begin > DH for generating session key. Server and client will use generated > session key for encryption and decryption of transmitted data. > > Is everything OK in this scenarion or not? > > On Aug 17, 11:43 am, Parch <[EMAIL PROTECTED]> wrote: > > > Sorry, I guess I overlooked something - if you've got a limited set of > > servers, then you don't need a trusted third party to verify the > > identities of 'new servers' that your application wishes to talk to; > > you can build the certification into the client application instead. > > > On Aug 17, 5:35 pm, Parch <[EMAIL PROTECTED]> wrote: > > > > If what you want to know is how to prevent man-in-the-middle attacks, > > > then I think this article might be helpful: > > > >http://www-128.ibm.com/developerworks/linux/library/l-openssl2.html?c... > > > > The essential point to remember is you have to be able to prove you > > > are communicating with a particular person/server (otherwise they > > > could be anyone). In general this requires there to be someone else > > > you trust -- which may or may not suit your application. > > > > On Aug 17, 2:34 am, Oleg <[EMAIL PROTECTED]> wrote: > > > > > Good day. > > > > > We have client-server. Each client use password for authentication, > > > > server has hashes of passwords. After successfull authentication > > > > client and server transmits some data. > > > > > We need to encrypt transmitting data. As I understand, reading this > > > > list, we need to generate session key and encrypt data, using this > > > > key. I found that DH - one of algorithms for session key generation. > > > > But it unsecure for the man-in-the-middle attack. Could we somehow use > > > > password hash to rise the security? > > > > > I would be very much obliged to you if you will give me some > > > > directions to google.- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
