You have only to look at TCP to solve this one. Until you get an Ack for Key received, lets proceed, you always use the Public key.
From: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment Connection establishment To establish a connection, TCP uses a 3-way handshake <http://en.wikipedia.org/wiki/Handshake_%28computing%29>. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs: 1. The active open is performed by sending a SYN to the server. 2. In response, the server replies with a SYN-ACK. 3. Finally the client sends an ACK (usually called SYN-ACK-ACK) back to the server. At this point, both the client and server have received an acknowledgement of the connection. Example: 1. The initiating host (client) sends a synchronization (SYN flag set) packet to initiate a connection. Any SYN packet holds a Sequence Number. The Sequence Number is a 32-bit field in TCP segment header. For example let the Sequence Number value for this session be x. 2. The other host receives the packet, records the Sequence Number of x from the client, and replies with an acknowledgment and synchronization (SYN-ACK). The Acknowledgment Number is a 32-bit field in TCP segment header. It contains the next sequence number that this host is expecting to receive (x + 1). The host also initiates a return session. This includes a TCP segment with its own initial Sequence Number value of y. 3. The initiating host responds with a next Sequence Number (x+1) and a simple Acknowledgment Number value of y + 1, which is the Sequence Number value of the other host + 1. dreijer wrote: > This does not relate specifically to Crypto++ but more to security in > general, but since I know there a several knowledgeable security users > in here I thought I'd ask the question anyway. > > Say you are establishing a secure channel over UDP between two > end-hosts, A and B. Both hosts know the public key of each other, and > thus the connection is bootstrapped using these keys. DH is used to > generate a temporary session key from which a symmetric key is derived. > The DH part of the security protocol is carried out using the public > keys. > > Now, my problem lies in the transition between using the public keys > and using the new symmetric key. Below I've outlined the last part of > the security protocol: > > Step 1: A -> B: { DH parameters }Kb+ > Step 2: B -> A: { DH parameters }Ka+ > Step 3: .... > > After Step 2, B expects all subsequent messages from A to be encrypted > using the symmetric key. However, what happens if the message from B to > A is dropped (since we're using UDP)? A will then resend Step 1 which > is encrypted using B's public key, rather than the symmetric key. How > does B know whether to use his private key or the symmetric key to > decrypt the message? > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cryptopp-users?hl=en -~----------~----~----~----~------~----~------~--~---
