Lines Matching refs:I
147 For I<in> (the L<OSSL_DISPATCH(3)> array passed from F<libcrypto> to the
199 For I<*out> (the L<OSSL_DISPATCH(3)> array passed from the provider to
216 core_get_params() retrieves parameters from the core for the given I<handle>.
222 thread eventually stops. It must be passed the I<handle> for this provider, as
223 well as a callback I<handfn> which will be called when the thread stops. The
224 callback will subsequently be called, with the supplied argument I<arg>, from
230 object for the current provider is stored, accessible through the I<handle>.
240 reference to the I<handle>.
254 The debugging information includes the name of the file I<file>, the
255 line I<line> and the function name I<func> where the error occurred.
261 sets the I<reason> for the error, along with any addition data.
262 The I<reason> is a number defined by the provider and used to index
265 The additional data is given as a format string I<fmt> and a set of
266 arguments I<args>, which are treated in the same manner as with
268 I<file> and I<line> may also be passed to indicate exactly where the
276 I<sn> and long name I<ln> for the given I<handle>. It is similar to the OpenSSL
279 short name I<sn> or long name I<ln> provided as arguments differ from those
284 (I<sign_name>) consisting of an underlying signature algorithm (I<pkey_name>)
285 and digest algorithm (I<digest_name>) for the given I<handle>. It assumes that
293 underlying signature or digest algorithm). For I<digest_name>, NULL or an
314 The seeding material will have at least I<entropy> bytes of randomness and the
315 output will have at least I<min_len> and at most I<max_len> bytes.
316 The buffer address is stored in I<*pout> and the buffer length is
331 get_nonce() retrieves a nonce using the passed I<salt> parameter
332 of length I<salt_len> and operating system specific information.
333 The I<salt> should contain uniquely identifying information and this is
335 The output is stored in a buffer which contains at least I<min_len> and at
336 most I<max_len> bytes. The buffer address is stored in I<*pout> and the
353 I<handle> is this provider's handle and I<cbdata> is this provider's data
359 I<create_cb> is a callback that will be called when a new provider is loaded
363 provider's data in I<cbdata>. It should return 1 on success or 0 on failure.
365 I<remove_cb> is a callback that will be called when a new provider is unloaded
367 the provider being unloaded and this provider's data in I<cbdata>. It should
370 I<global_props_cb> is a callback that will be called when the global properties
380 I<handle>.
383 with the provider identified by I<prov>.
386 identified by I<prov> when it initialised.
388 provider_up_ref() increments the reference count on the provider I<prov>. If
389 I<activate> is nonzero then the provider is also loaded if it is not already
392 provider_free() decrements the reference count on the provider I<prov>. If
393 I<deactivate> is nonzero then the provider is also unloaded if it is not
400 It must free the passed I<provctx>.
407 I<params>, setting the values of the parameters it understands.
410 that corresponds to the given I<operation_id>.
412 setting I<*no_store> to 0 (core may store a reference) or 1 (core may
417 pointers have been copied. The I<operation_id> should match that passed to
418 provider_query_operation() and I<algs> should be its return value.
424 The provider_get_capabilities() function should call the callback I<cb> passing
425 it a set of L<OSSL_PARAM(3)>s and the caller supplied argument I<arg>. The
427 in the I<capability> argument relevant for the provider context I<provctx>. If a
556 I<key exchange> (KEX) or I<key encapsulation method> (KEM) during a TLS
587 be used with this group. Keys created should be able to support I<key exchange>
588 or I<key encapsulation method> (KEM), as implied by the optional
603 Boolean flag to describe if the group should be used in I<key exchange> (KEX)
604 mode (0, default) or in I<key encapsulation method> (KEM) mode (1).
609 In KEX mode, in a typical Diffie-Hellman fashion, both sides execute I<keygen>
610 then I<derive> against the peer public key. To operate in KEX mode, the group
614 In KEM mode, the client executes I<keygen> and sends its public key, the server
615 executes I<encapsulate> using the client's public key and sends back the
616 resulting I<ciphertext>, finally the client executes I<decapsulate> to retrieve
617 the same I<shared secret> generated by the server's I<encapsulate>. To operate
621 Both in KEX and KEM mode, the resulting I<shared secret> is then used according
