This comes with all the warnings about designing your own protocol [extensions]. And since you are concerned about quantum computing attacks, you should evaluate the other parts used in setting up and maintaining connections as well (digests, the works). I can't help you with those; seek professional cryptographer advise for that.
Barring that, and given your desire for a 'compatible fallback mechanism, a possible implementation *suggestion* might be to use, or at least piggy-back on, TLS-PSK - which is at least available in 0.9.9 CVS HEAD. This is a protocol extension for 'pre-shared keys', which sounds quite a lot like the thing you have. Check out the protocol specs for that; implementation-wise, OpenSSL comes with client- and server-side callbacks, where you can attach your own code which uses your smartcard-stored 'shared secret'. Check the protocol and implementation to find how such data travels across the line (at least it gets a digest attached through calling generate_master_secret(), but I didn't look any further, so beware, don't just drop stuff in there and expect to be safe. Protocol-wise, given your 'fallback' requirement, think the other way around: this is what [key] renegotiation was made for (well, not only that, but anyway): OpenSSL offers this as part of the API, though renegotiation is usually used to request client certificates and such as a way to step up the security level. It may well be that changing over to PSK for the REnegotiation phase only (i.e. halfway during an already established connection) is not possible at the moment: I don't know, haven't looked all that deep into PSK yet myself. (Just glanced at it, 's all.) > It is clearly important that the modified version of the SSL protocol > remains interoperable with unmodified SSL/TLS implementations and that the > modified protocol does not interfere with the stability of the established > SSL/TLS user base. If you find a way to fit it in like that, you ride within the existing protocol(s), so interoperability is maximized there. Given that PSK is already available in OpenSSL, you don't need to hack that bit. If you need more than this, the next stage is to set up your own key exchange, i.e. derive from SSL_aPSK and SSL_kPSK-enabled code sections, and go from there, but that way, madness (or at least LOTS of security issues) lies - as that would turn into designing your own protocols, and we all know what good that's doing to everybody. ;-) (Half the mailing list will be popping migraine pills by now.) Be careful, -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
