<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="">Shane’s major complaints are about the indirection the OSSL_PARAM structure forces — for integers and return lengths and the necessity of allocating additional memory in parallel with the OSSL_PARAM.<div class=""><br class=""></div><div class="">The extra indirection was intended to support const arrays of OSSL_PARAM, which turn out to be a rarity because they aren’t thread safe.  With most OSSL_PARAM structure being dynamically created, the need for the indirection seems redundant.  E.g. could the return length be moved into OSSL_PARAM?  I think so.</div><div class=""><br class=""></div><div class="">Moving integral values into the structure is more difficult because BIGNUMs will always need to be references.  Allocating additional memory will still be required.  I’ve got three obvious solutions:</div><div class=""><br class=""></div><div class="">1. include a void * in the OSSL_PARAM structure that needs to be freed when the structure is destroyed or</div><div class="">2. have a block of data in the OSSL_PARAM structure that can be used for native types (OSSL_UNION_ALIGN works perfectly for this) or</div><div class="">3. add a flag field to the OSSL_PARAM to indicate that the referenced value needs to be freed.</div><div class=""><br class=""><div class="">The memory allocation comes to the for when reading e.g. a file and extracting data — either the reader needs a lot of local variables to hold everything or it has to allocated for each.  The file’s data is transient in memory.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">For the most part, the receiver side APIs seem reasonable.  It is the owning side that has the complications.</div><div class=""><br class=""></div><div class=""><div class="">I think I might be able come up with some owner side routines that assist here but allowing changes to the params structure would be far easier.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I kind of like using the OSSL_PARAM arrays as a replacement for string ctrl functions if not ctrl as well (subject to backward compatibility concerns).</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 4 Jun 2019, at 11:26 pm, Richard Levitte <<a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Tue, 04 Jun 2019 14:57:00 +0200,<br class="">Salz, Rich wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">   Part of the idea was that this would be a means of communication<br class=""></blockquote>    between application and provider, just like controls are with<br class="">    libcrypto sub-systems.<br class=""><br class=""><br class="">I can probably find the email thread (or maybe it was a GitHub<br class="">comment on my proposal for params), where you said, quite<br class="">definitively, that this was *not* a general-purpose mechanism but<br class="">rather a way to expose the necessary internals for opaque objects<br class="">like RSA keys.<br class=""></blockquote><br class="">Either I misunderstood what you said at the time, or you misunderstood<br class="">what I said...  there's definitely a disconnect here somewhere.<br class=""><br class="">What I wonder is why it should be exclusively only one of those<br class="">options?<br class=""><br class="">Either way, the OSSL_PARAM is defined publically and openly (i.e.<br class="">non-opaque), and we currently have the following functions in the<br class="">public API:<br class=""><br class="">    EVP_MD_CTX_set_params<br class="">    EVP_MD_CTX_get_params<br class="">    OSSL_PROVIDER_get_params<br class=""><br class="">I fully expect that more will come.  I have a branch where I've<br class="">EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if<br class="">EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before<br class="">long (I'm actually rather surprised they haven't already), and I'm<br class="">absolutely sure we will see similar functions for asymmetric<br class="">algorithms.<br class=""><br class=""><blockquote type="cite" class="">What changed your mind?<br class=""><br class="">Perhaps not surprisingly, I agree with Shane's assessment and am<br class="">strongly opposed to the project foisting this on everyone at this<br class="">time.  @DavidBen, your thoughts?<br class=""></blockquote><br class="">Maybe we're reading differently, I didn't see Shane being opposed to<br class="">parameter passing in this way per se, just the exact form of the<br class="">OSSL_PARAM structure, which is different.<br class=""><br class="">Cheers,<br class="">Richard<br class=""><br class="">-- <br class="">Richard Levitte         <a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a><br class="">OpenSSL Project         <a href="http://www.openssl.org/~levitte/" class="">http://www.openssl.org/~levitte/</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>