On 05/10/16 20:59, David Woodhouse wrote: > >> >> >> On 05/10/16 15:37, David Woodhouse wrote: >>> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >>>> How's this for a start... >>> >>> Now I think I have it right for CCM too, although having to use >>> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... >>> and then maybe I can stop worrying about new modes and ciphersuites >>> because those won't be added in OpenSSL 1.1 and we can get OpenSSL do >>> to this for itself before 1.2? :) >> >> Or even 1.1.1! Why don't you pull this together into a github PR? > > Sure. Any thoughts on what you want it to look like? Not just > SSL_CIPHER_get_overhead() because it'seems not constant -- you have to > account for blocksize rounding and padding in CBC ciphers. So just > SSL_CIPHER_get_data_mtu(int link_mtu)?
Hmmmm....well its not constant even by cipher. It depends on the transport (IPv6 has a bigger overhead than IPv4). We already have: DTLS_set_link_mtu(SSL *s, int mtu) So why not: DTLS_get_data_mtu(SSL *s) > > Or are there other use cases we want it for, and we *should* try returning > a full set of three "add this, round up to this, add this" integers? > > As for the actual numbers... am I on the right track so far? > I've not thought about it in great detail, but it looks ok at first glance. Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
