<div dir="auto">"handle" is the wrong name for this - if you want to have private const data then do that rather than something which might be abused for instance specific information. It could just be an int even or a short. It doesn't have to be a pointer.<div dir="auto"><br></div><div dir="auto">That would reduce the likely of it being used to hold non-const data.<br><div dir="auto"><div dir="auto"><br></div><div dir="auto">Tim.</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 23 Mar. 2019, 9:11 am Dr Paul Dale <<a href="mailto:paul.dale@oracle.com">paul.dale@oracle.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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><br></div><div>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><br></div><div>I don’t think we should be doing a string lookup every time one of these is called.</div><div><br></div><div><br></div><div>Of the three, the provider data feels clean and unique functions fast.</div><div><br></div><div>I’d like to avoid mandating another level of indirection (it’s slow), which is a risk with provider data.</div><div><br></div><div><br></div><div>My thought: add the provider data field. Use that when it can be done directly, use unique functions otherwise.</div><div>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><br></div><div><br></div><div><br></div><div>Pauli<br><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">-- <br>Dr Paul Dale | Cryptographer | Network Security & Encryption <br>Phone +61 7 3031 7217<br>Oracle Australia</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><br class="m_-2340244739398794525Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On 23 Mar 2019, at 1:45 am, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank" rel="noreferrer">matt@openssl.org</a>> wrote:</div><br class="m_-2340244739398794525Apple-interchange-newline"><div><div>Currently we have the OSSL_ALGORITHM type defined as follows:<br><br>struct ossl_algorithm_st {<br> const char *algorithm_name; /* key */<br> const char *property_definition; /* key */<br> const OSSL_DISPATCH *implementation;<br>};<br><br>I'm wondering whether we should add an additional member to this structure: a<br>provider specific handle. i.e.<br><br>struct ossl_algorithm_st {<br> const char *algorithm_name; /* key */<br> const char *property_definition; /* key */<br> const OSSL_DISPATCH *implementation;<br> void *handle;<br>};<br><br>The reason to do this is because providers are likely to want to share the same<br>implementation across multiple algorithms, e.g. the init/update/final functions<br>for aes-128-cbc are likely to look identical to aes-256-cbc with the only<br>difference being the key length. A provider could use the handle to point to<br>some provider side structure which describes the details of the algorithm (key<br>length, IV size etc). For example in the default provider we might have:<br><br>typedef struct default_alg_handle_st {<br> int nid;<br> size_t keylen;<br> size_t ivlen;<br>} DEFAULT_ALG_HANDLE;<br><br>DEFAULT_ALG_HANDLE aes256cbchandle = { NID_aes_256_cbc, 32, 16 };<br>DEFAULT_ALG_HANDLE aes128cbchandle = { NID_aes_128_cbc, 16, 16 };<br><br>static const OSSL_ALGORITHM deflt_ciphers[] = {<br> { "AES-256-CBC", "default=yes", aes_cbc_functions, &aes256cbchandle },<br> { "AES-128-CBC", "default=yes", aes_cbc_functions, &aes128cbchandle },<br> { NULL, NULL, NULL }<br>};<br><br>Then when the "init" function is called (or possibly at newctx), the core passes<br>as an argument the provider specific handle associated with that algorithm.<br><br>An alternative is for the provider to pass the algorithm name instead, but this<br>potentially requires lots of strcmps to identify which algorithm we're dealing<br>with which doesn't sound particularly attractive.<br><br>A second alternative is for each algorithm to always have unique functions<br>(which perhaps call some common functions underneath). This sounds like lots of<br>unnecessary redundancy.<br><br>Thoughts?<br><br>Matt<br></div></div></blockquote></div><br></div></div></blockquote></div>