Implement TLS-PSK ciphersuites

[FiachAntaw]

This PR implements the TLS-PSK ciphersuites as defined in RFC4279.

• One new API has been added, handshakeClientPSK, which accepts a callback function returning the PSK identity and PSK based on an (optional) server-provided identity hint. A callback is used because the format of the identity hint is not specified in the RFC; this is consistent with the API exposed by OpenSSL. A typical example of a PSK identity hint might be a comma-separated list of all the PSK identities recognized by the server.
• A PskDB class has been added, associating PSK identities with PSKs in a manner similar to VerifierDB
• The handshakeServer API has been extended with the addition of a pskDB parameter (accepting a PskDB database) and a pskIdentityHint parameter (sent to the client during key exchange, if present).
• A pskdb.py script has been added, allowing PskDB files to be created and edited.
• The tls.py script has been extended to support TLS-PSK ciphersuites.
• Test-cases for the TLS-PSK ciphersuites have been added (though 'make test' currently fails due to #107).

[tomato42]

please rebase on top of master, don't merge master to a pull request

[FiachAntaw]

Sorry about that, hopefully this should fix it.

[FiachAntaw]

Thanks for the review, I'll try to fix the issues you've pointed out soon.

this will generate a prime 32 bits long...

Ouch, good catch! I'm sorry to say that I just copied that line from _serverAnonKeyExchange without thinking (see tlsconnection.py lines 1600-1604).

I'll refactor the DH/RSA parameter selection into separate methods like you suggest, is there any particular reason why anonymous key exchange uses such a small prime or should I change it at the same time?

how does that differ from setting an incorrect pskIdentity or psk?

It doesn't, I'll drop it and change the tests accordingly.

serverName="" will send an empty SNI, use None

All the handshakeClient* methods seem to use serverName="", if I'm not mistaken. I'd prefer to maintain consistency with the other public functions for this patchset; though it does seem to be an oversight rather than an intentional choice (especially since a blank server_name could trigger an unrecognized_name alert per the RFC).

[tomato42]

is there any particular reason why anonymous key exchange uses such a small prime or should I change it at the same time?

no, it's a bug too, I just quickly patched it in my fork to make DHE work with OpenSSL post Logjam and planned to do a proper solution with configurable settings

a separate pull request would be better - it's a trivial change so easier to merge