<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’ve no issue having a provider data field there. It will be useful for more than just this (S390 AES e.g. holds data differently to other implementations).<div class=""><br class=""></div><div class="">I also don’t think forcing separate functions is a big problem — most providers will only implement one or two algorithm families which will help control the redundancy.</div><div class=""><br class=""></div><div class="">I don’t think we should be doing a string lookup every time one of these is called.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Of the three, the provider data feels clean and unique functions fast.</div><div class=""><br class=""></div><div class="">I’d like to avoid mandating another level of indirection (it’s slow), which is a risk with provider data.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">My thought: add the provider data field. Use that when it can be done directly, use unique functions otherwise.</div><div class="">The example with key and iv lengths would be a direct use. Code that dives through a function pointer or a switch statement would be an example of not.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Pauli<br class=""><div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">-- <br class="">Dr Paul Dale | Cryptographer | Network Security & Encryption <br class="">Phone +61 7 3031 7217<br class="">Oracle Australia</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""></div><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 23 Mar 2019, at 1:45 am, Matt Caswell <<a href="mailto:matt@openssl.org" class="">matt@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Currently we have the OSSL_ALGORITHM type defined as follows:<br class=""><br class="">struct ossl_algorithm_st {<br class=""> const char *algorithm_name; /* key */<br class=""> const char *property_definition; /* key */<br class=""> const OSSL_DISPATCH *implementation;<br class="">};<br class=""><br class="">I'm wondering whether we should add an additional member to this structure: a<br class="">provider specific handle. i.e.<br class=""><br class="">struct ossl_algorithm_st {<br class=""> const char *algorithm_name; /* key */<br class=""> const char *property_definition; /* key */<br class=""> const OSSL_DISPATCH *implementation;<br class=""> void *handle;<br class="">};<br class=""><br class="">The reason to do this is because providers are likely to want to share the same<br class="">implementation across multiple algorithms, e.g. the init/update/final functions<br class="">for aes-128-cbc are likely to look identical to aes-256-cbc with the only<br class="">difference being the key length. A provider could use the handle to point to<br class="">some provider side structure which describes the details of the algorithm (key<br class="">length, IV size etc). For example in the default provider we might have:<br class=""><br class="">typedef struct default_alg_handle_st {<br class=""> int nid;<br class=""> size_t keylen;<br class=""> size_t ivlen;<br class="">} DEFAULT_ALG_HANDLE;<br class=""><br class="">DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 };<br class="">DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 };<br class=""><br class="">static const OSSL_ALGORITHM deflt_ciphers[] = {<br class=""> { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle },<br class=""> { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle },<br class=""> { NULL, NULL, NULL }<br class="">};<br class=""><br class="">Then when the "init" function is called (or possibly at newctx), the core passes<br class="">as an argument the provider specific handle associated with that algorithm.<br class=""><br class="">An alternative is for the provider to pass the algorithm name instead, but this<br class="">potentially requires lots of strcmps to identify which algorithm we're dealing<br class="">with which doesn't sound particularly attractive.<br class=""><br class="">A second alternative is for each algorithm to always have unique functions<br class="">(which perhaps call some common functions underneath). This sounds like lots of<br class="">unnecessary redundancy.<br class=""><br class="">Thoughts?<br class=""><br class="">Matt<br class=""></div></div></blockquote></div><br class=""></div></body></html>