21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Discussion<br />

Remember, authentication requires a trusted third party or a secure<br />

channel for exchange of public DSA keys. If you’d prefer a passwordbased<br />

protocol that can achieve all the same properties you would get<br />

from Diffie-Hellman and DSA, see the discussion of PAX in Recipe 8.15.<br />

Given a client initiating a connection with a server, the station-to-station protocol is<br />

as follows:<br />

1. The client generates a random Diffie-Hellman secret x and the corresponding<br />

public value A.<br />

2. The client sends A to the server.<br />

3. The server generates a random Diffie-Hellman secret y and the corresponding<br />

public value B.<br />

4. The server computes the Diffie-Hellman shared secret.<br />

5. The server signs a string consisting of the public values A and B with the server’s<br />

private DSA key.<br />

6. The server sends B and the signature to the client.<br />

7. The client computes the shared secret.<br />

8. The client validates the signature, failing if it isn’t valid.<br />

9. The client signs A concatenated with B using its private DSA key, and it encrypts<br />

the result using the shared secret (the secret can be postprocessed first, as long as<br />

both sides do the same processing).<br />

10. The client sends the encrypted signature to the server.<br />

11. The server decrypts the signature and validates it.<br />

The station-to-station protocol works only if your Diffie-Hellman keys are always<br />

one-time values. If you need a protocol that doesn’t expose the private values of each<br />

party, use Recipe 8.16. That basic protocol can be adapted from RSA to Diffie-Hellman<br />

with DSA if you so desire.<br />

Unless you allow for anonymous connection establishment, the client needs to identify<br />

itself as part of this protocol. The client can send its public key (or a digital certificate<br />

containing the public key) at Step 2. The server should already have a record of<br />

the client based on its public key, or else it should fail. Alternatively, you can drop<br />

the client validation steps (9–11) and use a traditional login mechanism after the<br />

encrypted link is established.<br />

Using Diffie-Hellman and DSA Together | 437<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!