<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=""><div class="">I presume the reference approach was used to solve the issue of who actually owns/free's the data.</div><div class=""> <div class=""><div class="">
<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; 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;"><br class=""></div></div><div><blockquote type="cite" class=""><div class="">On 5 Jun 2019, at 9:18 am, Dr Paul Dale <<a href="mailto:paul.dale@oracle.com" class="">paul.dale@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" 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.</span><div class="" style="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; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="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; -webkit-text-stroke-width: 0px;">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="" style="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; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="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; -webkit-text-stroke-width: 0px;">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="" style="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; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="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; -webkit-text-stroke-width: 0px;">1. include a void * in the OSSL_PARAM structure that needs to be freed when the structure is destroyed or</div><div class="" style="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; -webkit-text-stroke-width: 0px;">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="" style="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; -webkit-text-stroke-width: 0px;">3. add a flag field to the OSSL_PARAM to indicate that the referenced value needs to be freed.</div><div class="" style="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; -webkit-text-stroke-width: 0px;"><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="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; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">-- <br class="">Dr Paul Dale | Cryptographer | Network Security & Encryption <br class="">Phone +61 7 3031 7217<br class="">Oracle Australia</div><div style="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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><br class="Apple-interchange-newline"></div><div class=""><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="">--<span class="Apple-converted-space"> </span><br class="">Richard Levitte <a href="mailto:levitte@openssl.org" class="">levitte@openssl.org</a><br class="">OpenSSL Project <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org_-7Elevitte_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk&m=ngbUohXK9OQMcC6T1S9Xvhy8OvC7dSslJ9RwAfHWnek&s=pbKG4wSDo_zd6yyp8bCPGDKXxFbG0-M5B4SRDEB-XA4&e=" class="">http://www.openssl.org/~levitte/</a></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></div></body></html>