On Fri, Feb 8, 2013 at 12:11 AM, T J <jordan.tre...@gmail.com> wrote:
>> TLS keying material exporter, i.e., SSL_export_keying_material(), will
>> make your life much easier if you are just looking for a mechanism to
>> derive suitable keys for other uses assuming you are using recent
>> enough OpenSSL. That tls_openssl.c file I mentioned above has an
>> example of this, too.
> Thanks very much Jouni - I think that will work nicely! Now if only there
> was some documentation on it...
I happened to had implemented the ugly way before and reviewed the RFC
describing this functionality, so never had to try to find
documentation.. RFC 5705 describes the mechanism it high level. I'm
not sure whether the OpenSSL implementation is documented somewhere.
> So to get a key, I would just establish the TLS connection, then use:
>
> if (!SSL_export_keying_material(mySsl, key, key_len, label, label_len, NULL,
> 0, 0))
> {
> //handle error
> }
>
> before closing the connection?
After having completed TLS handshake and before closing the connection, yes.
> Do that on both ends and I have my symmetric
> keys for use in my app(s).
> (My app uses a completely seperate radio path for bulk data encrypted using
> specialised hardware - hence my requirement for a key.)
That's pretty much what I'm using this for, too, with EAP, i.e., only
authenticate and derive the key with TLS. SSL_export_keying_material()
works fine for that as long as you do not need to meet some protocol
design where key derivation is defined in a way that does not match
the functionality defined in RFC 5705.
- Jouni
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
