Re: OTC VOTE: Fixing missing failure exit status is a bug fix

2020-11-30 Thread SHANE LONTIS
+1


> On 30 Nov 2020, at 10:03 pm, Nicola Tuveri  wrote:
> 
> Vote background
> ---
> 
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the attending
> members that also sit in the OMC.
> 
> The suggestion was to improve the separation of the OTC and OMC domains
> here, by having a more generic OTC vote to qualify as bug fixes the
> changes to let any OpenSSL app return an (early) failure exit status
> when a called function fails.
> 
> The idea is that, if we agree on this technical definition, then no OMC
> vote to allow a behavior change in the apps would be required in
> general, unless, on a case-by-case basis, the "OMC hold" process is
> invoked for whatever reason on the specific bug fix, triggering the
> usual OMC decision process.
> 
> [previous proposal]:
>   >
> [PR#13359]: 
>   >
> 
> 
> 
> Vote text
> -
> 
> topic: In the context of the OpenSSL apps, the OTC qualifies as bug
>   fixes the changes to return a failure exit status when a called
>   function fails with an unhandled return value.
>   Even when these bug fixes change the apps behavior triggering
>   early exits (compared to previous versions of the apps), as bug
>   fixes, they do not qualify as behavior changes that require an
>   explicit OMC approval.
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-11-30



Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread SHANE LONTIS
Key assurance  really depends on what you are doing, so I don't think this is 
quite true.
For example if you generate a key using a valid algorithm (that is validated by 
a lab), then there is already an assurance that the key is valid without 
needing to run EVP_PKEY_check().

There are many operations that don't need EVP_PKEY_check, but they may need a 
sub check such as
EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or 
EVP_PKEY_pairwise_check (or some combination of those).
Keys (and certs) that are received from another entity should be validated 
unless there is some other mechanism for establishing that the key is trusted.


> On 12 Nov 2020, at 12:14 am, Nicola Tuveri  wrote:
> 
> In light of recently working more closely to `EVP_PKEY_check()` I
> would add to the discussion on this vote that it is not entirely true
> that we were not enforcing the keypair assumption and that the current
> strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t.
> some uses that work in 1.1.1.
> 
> In particular in 1.1.1, the key created as depicted in #12612 that
> triggered this discussion (Matt posted a useful reproducer among the
> first comments), is indeed capable of signing in the used pattern, but
> the pattern is conveniently omitting the validation pass that should
> be required in any serious use of the API.
> 
> `EVP_PKEY_check()`
> (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$
>  ) is
> one of the many places in 1.1.1 where both the documentation and the
> behavior assume that an `EVP_PKEY` object is a keypair.
> Even in the version used by the user that posted the issue, running
> `EVP_PKEY_check()` on the created key would have revealed that the
> user was abusing the API.
> 
> The "lack of enforcement" argument, that was partially at the base of
> formulating the vote text as it is, and conditioned our votes, seems
> to me an intentional design choice, as part of preferring the usage
> pattern "validate once, and reuse many times": for performance reasons
> we are not running `EVP_PKEY_check()` on every single key loaded from
> a PEM file or created by the user, but there is an assumption that the
> user did validate at least once the key material using
> `EVP_PKEY_check()` or `openssl pkey -check`.
> So enforcement was never lacking, but it was relegated together with
> more expensive checks, into functions that the user should execute at
> least once, possibly according to well documented security policies
> concerning the management of key material in transit and at rest.
> 
> Omitting the `EVP_PKEY_check()` in the reproducer and the user
> application, would for example allow me to write a DoS attack: the
> secret scalar could easily be hand-picked to trigger an endless loop
> in the sign operation.
> 
> 
> --
> 
> Nicola
> 
> 
> 
> On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell  wrote:
>> 
>> Background to the vote:
>> 
>> The OTC meeting today discussed the problems raised by issue #12612. In
>> summary the problem is that there has been a long standing, widespread
>> and documented assumption that an EVP_PKEY with a private key will
>> always also have the public key component.
>> 
>> In spite of this it turns out that in the EC implementation in 1.1.1 it
>> was perfectly possible to create an EVP_PKEY with only a private key and
>> no public key - and it was also possible to use such an EVP_PKEY in a
>> signing operation.
>> 
>> The current 3.0 code in master introduced an explicit check (in line
>> with the long held assumption) that the public key was present and
>> rejected keys where this was not the case. This caused a backwards
>> compatibility break for some users (as discussed at length in #12612).
>> 
>> The OTC discussed a proposal that we should relax our conceptual model
>> in this regards and conceptually allow EVP_PKEYs to exist that only have
>> the private component without the public component - although individual
>> algorithm implementations may still require both.
>> 
>> It is possible to automatically generate the public component from the
>> private for many algorithms, although this may come at a performance and
>> (potentially) a security cost.
>> 
>> The proposal discussed was that while relaxing the conceptual model,
>> most of the existing implementations would still require both. The EC
>> implementation would be relaxed however. This essentially gives largely
>> compatible behaviour between 1.1.1 and 3.0.
>> 
>> The vote text is as follows:
>> 
>> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
>> * relax the conceptual model to allow private keys to exist without public
>>  components;
>> * all implementations apart from EC require the public component to be
>> present;
>> * relax implementation for EC key management to allow private keys that
>> do not
>>  contain public keys 

Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch

2020-10-10 Thread SHANE LONTIS
0

> On 9 Oct 2020, at 10:02 pm, Tomas Mraz  wrote:
> 
> topic: The PR #11359 (Allow to continue with further checks on
> UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
> As the change is borderline on bug fix/behaviour change OTC needs
> to decide whether it is acceptable for 1.1.1 branch.
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-10-09
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>  Matt   [  ]
>  Mark   [  ]
>  Pauli  [  ]
>  Viktor [  ]
>  Tim[  ]
>  Richard[  ]
>  Shane  [  ]
>  Tomas  [+1]
>  Kurt   [  ]
>  Matthias   [  ]
>  Nicola [  ]
> 
> -- 
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>  Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
> 
> 



Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released

2020-10-09 Thread SHANE LONTIS
[+1]  (reluctantly committing to 3 hour meetings :))


> On 9 Oct 2020, at 10:00 pm, Nicola Tuveri  wrote:
> 
> topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13
>   and until 3.0 beta1 is released, in lieu of the weekly "developer
>   meetings".
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-10-09
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>  Matt   [  ]
>  Mark   [  ]
>  Pauli  [  ]
>  Viktor [  ]
>  Tim[  ]
>  Richard[  ]
>  Shane  [  ]
>  Tomas  [  ]
>  Kurt   [  ]
>  Matthias   [  ]
>  Nicola [+1]



Re: VOTE: Technical Items still to be done

2020-10-08 Thread SHANE LONTIS
+1



> On 9 Oct 2020, at 12:47 am, Matt Caswell  wrote:
> 
> topic: The following items are required prerequisites for the first beta
> release:
> 1) EVP is the recommended API, it must be feature-complete compared with
>the functionality available using lower-level APIs.
>   - Anything that isn’t available must be put to an OTC vote to exclude.
>   - The apps are the minimum bar for this, subject to exceptions noted
> below.
> 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_,
>RAND_METHOD_.
>   - Does not include macros defining useful constants (e.g.
> SHA512_DIGEST_LENGTH).
>   - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`.
>   - There might be some others.
>   - Review for exceptions.
>   - The apps are the minimum bar to measure feature completeness for
> the EVP
> interface: rewrite them so they do not use internal nor deprecated
> functions (except speed, engine, list, passwd -crypt and the code
> to handle
> the -engine CLI option).  That is, remove the suppression of deprecated
> define.
> - Proposal: drop passwd -crypt (OMC vote required)
>   - Compile and link 1.1.1 command line app against the master headers and
> library.  Run 1.1.1 app test cases against the chimera.  Treat this
> as an
> external test using a special 1.1.1 branch. Deprecated functions
> used by
> libssl should be moved to independent file(s), to limit the
> suppression of
> deprecated defines to the absolute minimum scope.
> 3) Draft documentation (contents but not pretty)
>   - Need a list of things we know are not present - including things we
> have
> removed.
>   - We need to have mapping tables for various d2i/i2d functions.
>   - We need to have a mapping table from “old names” for things into the
> OSSL_PARAMS names.
> - Documentation addition to old APIs to refer to new ones (man7).
> - Documentation needs to reference name mapping.
> - All the legacy interfaces need to have their documentation
> pointing to
>   the replacement interfaces.
> 4) Review (and maybe clean up) legacy bridge code.
> 5) Review TODO(3.0) items #12224.
> 6) Source checksum script.
> 7) Review of functions previously named _with_libctx.
> 8) Encoder fixes (PKCS#8, PKCS#1, etc).
> 9) Encoder DER to PEM refactor.
> 10) Builds and passes tests on all primary, secondary and FIPS platforms.
> 11) Query provider parameters (name, version, ...) from the command line.
> 12) Setup buildbot infrastructure and associated instructions.
> 13) Complete make fipsinstall.
> 14) More specific decoding selection (e.g. params or keys).
> 15) Example code covering replacements for deprecated APIs.
> 16) Drop C code output options from the apps (OMC approval required).
> 17) Address issues and PRs in the 3.0beta1 milestone.
> Proposed by .
> Public: yes
> opened: 2020-10-08
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>  Matt   [+1]
>  Mark   [  ]
>  Pauli  [  ]
>  Viktor [  ]
>  Tim[  ]
>  Richard[  ]
>  Shane  [  ]
>  Tomas  [  ]
>  Kurt   [  ]
>  Matthias   [  ]
>  Nicola [  ]



Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread SHANE LONTIS
-1


> On 9 Oct 2020, at 7:40 am, Dr Paul Dale  wrote:
> 
> +1
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 9 Oct 2020, at 12:27 am, Matt Caswell > > wrote:
>> 
>> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
>> shown in PR #13018 into the 3.0 release
>> Proposed by Matt Caswell
>> Public: yes
>> opened: 2020-10-08
>> closed: 2020-mm-dd
>> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>> 
>>  Matt   [+1]
>>  Mark   [  ]
>>  Pauli  [  ]
>>  Viktor [  ]
>>  Tim[  ]
>>  Richard[  ]
>>  Shane  [  ]
>>  Tomas  [  ]
>>  Kurt   [  ]
>>  Matthias   [  ]
>>  Nicola [  ]
> 



Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread SHANE LONTIS
I assume you are just talking about the ec key?

If the public key is not present then that could be seen as an error for 
operations that require the public key. 

Shane

> On 7 Oct 2020, at 9:54 pm, Dr Paul Dale  wrote:
> 
> Would it be feasible to change code that does ->pub_key to call a function 
> that null checks the field and generates the public key if it is absent?
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 7 Oct 2020, at 9:29 pm, Matt Caswell > > wrote:
>> 
>> Issue #12612 exposes a problem with how we handle keys that contain
>> private components but not public components.
>> 
>> There is a widespread assumption in the code that keys with private
>> components must have public components. There is text in our public
>> documentation that states this (and that text dates back to 2006).
>> 
>> OTOH, the code has not always enforced this. Issue #12612 describes a
>> scenario where this has not historically been enforced, and it now is in
>> the current 3.0 code causing a regression.
>> 
>> There are differences of opinion on how this should be handled. Some
>> have the opinion that we should change the model so that we explicitly
>> allow private keys to exists without the public components. Others feel
>> that we should continue with the old model.
>> 
>> It seems we need a vote to decide this. Here is my proposed vote text:
>> 
>> We should change the 3.0 code to explicitly allow private components to
>> exist in keys without the public components also being present.
>> 
>> Feedback please on the proposed vote text.
>> 
>> Matt
> 



Re: Freeze?

2020-09-25 Thread SHANE LONTIS
I think this best describes the issue:
https://www.youtube.com/watch?v=zsKOYQ7z9CE 



> On 26 Sep 2020, at 9:17 am, Benjamin Kaduk  wrote:
> 
> On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote:
>> I’m seeing quite a bit of activity going on which isn’t related to the 
>> 3.0beta1 milestone.
>> We’re well past the cutoff date announced for new features in the code.
>> 
>> Should we be limiting the “new” stuff going in?
>> 
>> I’m fine with bug fixes, they make sense.  I’m fine with the list of beta1 
>> pull requests continuing.
>> It’s the rest that is more concerning.
>> 
>> Does anyone else have a similar view?
> 
> I think we should probably avoid putting in large or potentially
> destabilizing changes, but don't see much reason to put a total freeze in
> place (even with your listed exceptions).
> 
> -Ben



Re: Reordering new API's that have a libctx, propq

2020-09-06 Thread SHANE LONTIS
The example given was EVP_PKEY_get_() and from the API name it is fairly clear 
what the first param should be EVP_PKEY *pkey (the API tells you this).

For the fetch case, I still think that the algorithm is the most important 
param.
Libctx, propq are optional parameters as far as I am concerned.

If it is decided that the libctx is more important then the API should really 
be something like this..
OSSL_LIBCTX_MD_fetch(), (and I dont know if that is a good idea.)..

In some places where libctx is used it is a second class parameter whose only 
job is to perform a sub task of fetching during a bigger operation (such as in 
a load),
And in these cases it should not be the first parameter..

Shane

> On 6 Sep 2020, at 4:02 pm, Richard Levitte  wrote:
> 
> There are many red herrings in here, and I would argue that trying to
> be too uniform in the way you think about all functions may be
> harmful, because not all functions are classified the same.
> 
> We cannot deny that many of our interfaces have an OOP flair.  We may
> be programming in C, but we very obviously have that kind of pattern,
> a "poor man's OOP" in C.  So speaking about our interfaces in OOP
> terms is not far fetched, as long as we keep in mind that we can only
> take the argument so far.
> 
> I would argue that EVP_XXX_get_whatever() / EVP_XXX_get_whatever() are
> classic accessors, and I assume that we have all been brought up with
> the description of "this" as the hidden first argument to any class
> method in C++, so it's not very far fetched to emulate that in C by
> making the instance you want details from or change details of as the
> (explicit) first argument.
> 
> I would further argue that EVP_XXX_fetch() is a constructor (of an
> instance of EVP_XXX), and that with the assumption that there is no
> "this" in a constructor, the discussion about the arguments and their
> order must be different.
> 
> What I hear, even though not in such terms, is an argument of the
> what the library context is and how that should affect the interface.
> In relation to EVP_XXX_fetch(), it seems to be more of a factory (or
> strictly speaking, the pool of resources, with hidden factory
> functions), and depending on the factory model you lean on, it might
> or might not be sensible to have it as first argument.  My you, I'm
> trying quite hard to see it from a fresh user experience (as far as I
> can imagine it...  after all, 20ish years with my fingers deep in
> OpenSSL entrails makes you not so fresh).
> 
> I think, BTW, that this really comes down to how we view the library
> context.  So far, I've seen all these interpretations (not all said
> explicitly, but clearly visible in code or how we argue about it):
> 
> - framework
> - scope (I'm unsure if that differs much from framework)
> - factory / factory pool
> - bag of resources
> 
> Personally, I have zero problems viewing it as all of these combined,
> but that requires us to be clear on how it's used in different places.
> 
> Cheers,
> Richard
> 
> On Sat, 05 Sep 2020 23:18:21 +0200,
> Tim Hudson wrote:
>> 
>> 
>> On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte  wrote:
>> 
>>I'd rank the algorithm name as the most important, it really can't do
>>anything of value without it.
>> 
>> It also cannot do anything without knowing which libctx to use. Look at the 
>> implementation.
>> Without the libctx there is no "from-where" to specify. 
>> 
>> This is again hitting the concept of where do things come from and what is a 
>> default.
>> Once "global" disappears as such, logically everything comes from a libctx.
>> 
>> Your argument is basically "what" is more important than "from" or "where".
>> And the specific context here is where you see "from" or "where" can be 
>> defaulted to a value so it
>> can be deduced so it isn't (as) important in the API.
>> 
>> That would basically indicate you would (applying the same pattern/rule in a 
>> different context)
>> change:
>> 
>> int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int *out);
>> 
>> To the following (putting what you want as the most important rather than 
>> from):
>> 
>> int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out);
>> 
>> Or pushing it right to the end after the output parameter:
>> 
>> int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey);
>> 
>> The context of where things come from is actually the most critical item in 
>> any of the APIs we
>> have.
>> Even though what you want to get from where you want to get it is in the 
>> point of the API call you
>> need to specify where from first as that context sets the frame of the call.
>> 
>> Think of it around this way - we could have an implementation where we 
>> remember the last key that
>> we have used and allow you to simply indicate you use the last key or if we 
>> didn't want the last
>> key used to be able to specify it via a non-NULL pointer. This isn't that 
>> unusual an API but not
>> something I'm 

Re: Reordering new API's that have a libctx, propq

2020-09-05 Thread SHANE LONTIS
Thanks for the writeup..

> My view is that the importance of arguments is what sets their order - and 
> that is why for the TYPE functions the TYPE pointer
> comes first. We could have just as easily specified it as last or some other 
> order, but we didn’t.

Isn’t that the order that the fetch is in if it changes to what it is in the 
PR? I would argue that the algorithm is the most important parameter in the 
fetch.

Deciding what argument is more ‘important’ is not always easy either.
If we are doing an operation such as a get or load and it needs a whole lot of 
input params in order to return something,
then aren’t they more important/ or just as important as the libctx,propq - 
(since the libctx,propq is just used normally to fetch something)?
This then means the libctx ends up last, or maybe in the middle again.

Also it is quite common for the new() methods (such as for X509) to need both 
the libctx and propq..
The X509 object gets passed to an d2i method that internally needs to do 
fetches (SHA1) and cache.

Shane

> On 5 Sep 2020, at 5:09 pm, Tim Hudson  wrote:
> 
> My view is that the importance of arguments is what sets their order - and 
> that is why for the TYPE functions the TYPE pointer
> comes first. We could have just as easily specified it as last or some other 
> order, but we didn't.



Reordering new API's that have a libctx, propq

2020-09-04 Thread SHANE LONTIS
PR #12778 reorders all the API’s of the form:

EVP_XX_fetch(libctx, algname, propq) 

So that the algorithm name appears first.. 

e.g: EVP_MD_fetch(digestname, libctx, propq);

This now logically reads as 'search for this algorithm using these parameters’.

The libctx, propq should always appear together as a pair of parameters.
There are only a few places where only the libctx is needed, which means that 
if there is no propq it is likely to cause a bug in a fetch at some point. 

This keeps the API’s more consistent with other existing XXX_with_libctx API’s 
that put the libctx, propq at the end of the parameter list..
The exception to this rule is that callback(s) and their arguments occur after 
the libctx, propq..

e.g:
typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
(const OSSL_STORE_LOADER *loader,
 const char *uri, OPENSSL_CTX *libctx, const char *propq,
 const UI_METHOD *ui_method, void *ui_data);

An otc_hold was put on this.. Do we need to have a formal vote?
This really needs to be sorted out soon so the API’s can be locked down for 
beta.


Also discussed in a weekly meeting and numerous PR discussions was the removal 
of the long winded API’s ending with ‘with_libctx’
e.g CMS_data_create_with_libctx
The proposed renaming for this was to continue with the _ex notation.. If there 
is an existing _ex name then it becomes _ex2, etc.
There will most likely be additional parameters in the future for some API’s, 
so this notation would be more consistent with current API’s.
Does this also need a vote?

Regards,
Shane




Re: RAND_DRBG

2020-07-26 Thread SHANE LONTIS

i.e.  Choose option (1)

> On 27 Jul 2020, at 11:14 am, SHANE LONTIS  wrote:
> 
> If this is not going to break 99% of users + it improves the interface + the 
> replacement to achieve the same is a few lines of code and is likely to occur 
> in one place in an app, then it seems reasonable to change it to me.
> 
> 
>> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > <mailto:paul.d...@oracle.com>> wrote:
>> 
>> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
>> with the move to provider based infrastructure.
>> They are definitely being deprecated in master but without more, the extra 
>> layer of indirection and additional complexity generating random numbers 
>> will remain.
>> 
>> The option I see are:
>> 
>> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking 
>> change.
>> 2. Bypass RAND_DRBG and live with a breaking change (refer: 
>> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 
>> <https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12509*pullrequestreview-455396828__;Iw!!GqivPVa7Brio!P_SYCN9POdf1ZT1I7v4h9G_oUTuels90DxKk1JmFkD7HcXsTPr9n0s3FX3XZZo_c2Q$>)
>> 3. Leave things as they currently are in master.
>> 
>> The first two are breaking changes and will require an OMC vote.
>> 
>> 
>> Some pertinent points:
>> 
>> 1. RAND_bytes will continue to work as is — this API is perfect for almost 
>> everyone.
>> 2. The RAND_METHOD functionality remains — this allows wholesale replacement 
>> of OpenSSL’s RNGs if desired.
>> 3. The name EVP_RAND is the working name and might change — this is not 
>> relevant to this discussion.
>> 4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced 
>> in 1.1.1.  The two users I know of (Akamai and NCP) are both fine with them 
>> being removed.
>> 
>> 
>> Thoughts anyone?
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
> 



Re: RAND_DRBG

2020-07-26 Thread SHANE LONTIS
If this is not going to break 99% of users + it improves the interface + the 
replacement to achieve the same is a few lines of code and is likely to occur 
in one place in an app, then it seems reasonable to change it to me.


> On 27 Jul 2020, at 11:08 am, Dr Paul Dale  wrote:
> 
> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
> with the move to provider based infrastructure.
> They are definitely being deprecated in master but without more, the extra 
> layer of indirection and additional complexity generating random numbers will 
> remain.
> 
> The option I see are:
> 
> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking 
> change.
> 2. Bypass RAND_DRBG and live with a breaking change (refer: 
> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 
> )
> 3. Leave things as they currently are in master.
> 
> The first two are breaking changes and will require an OMC vote.
> 
> 
> Some pertinent points:
> 
> 1. RAND_bytes will continue to work as is — this API is perfect for almost 
> everyone.
> 2. The RAND_METHOD functionality remains — this allows wholesale replacement 
> of OpenSSL’s RNGs if desired.
> 3. The name EVP_RAND is the working name and might change — this is not 
> relevant to this discussion.
> 4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced 
> in 1.1.1.  The two users I know of (Akamai and NCP) are both fine with them 
> being removed.
> 
> 
> Thoughts anyone?
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 



Re: API renaming

2020-07-24 Thread SHANE LONTIS
As @levitte pointed out - it was not back ported (not sure why I thought it 
was) 

> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre 
>  wrote:
> 
> > I think the KDF and MAC got back ported also...
>  
> In this case it would be no question that we should keep the names EVP_KDF 
> and EVP_MAC.
>  
>  
>Dr. Matthias 
> St. Pierre 
> 
> Senior Software Engineer 
> matthias.st.pie...@ncp-e.com  
> Phone: +49 911 9968-0
> www.ncp-e.com 
> 
> 
> Follow us on: Facebook 
> 
>  | Twitter 
> 
>  | Xing 
> 
>  | YouTube 
> 
>  | LinkedIn 
> 
> 
> Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
> Nuremberg 
> North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
> Clearwater, FL 33755 
> 
> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich 
> Registry Court: Lower District Court of Nuremberg 
> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
> 133557619
> 
> This e-mail message including any attachments is for the sole use of the 
> intended recipient(s) and may contain privileged or confidential information. 
> Any unauthorized review, use, disclosure or distribution is prohibited. If 
> you are not the intended recipient, please immediately contact the sender by 
> reply e-mail and delete the original message and destroy all copies thereof.
> 
> 



Re: API renaming

2020-07-24 Thread SHANE LONTIS
I was thinking OSSL_LIBCTX?

> On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre 
>  wrote:
> 
> I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with 
> Shane
> that we should go for a single prefix and not have two alternatives. Existing 
> prefixes
> for things like feature macros should remain as they are, but if the OSSL_ 
> prefix is
> our choice for the future, we should start using it consistently for _all_ 
> new APIs in 3.0.
> And not make it a random choice (pun intended) depending on whether the API 
> went
> into master early or late. So my favorite choice is a consistent renaming, 
> i.e.
> 
>   OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ...
> 
> OTOH, it would be ok for me if we would make an exception for EVP_MAC and 
> EVP_KDF,
> because they have a long EVP history, as Matt pointed out. But using the EVP_ 
> prefix
> for the new RAND interface never made sense to me.
> 
> What bothers me about OPENSSL_CTX in particular is the fact that it is a 
> mixture of
> a non-abbreviated and an abbreviated word. IMHO it should be either OSSL_CTX 
> or
> OPENSSL_CONTEXT, and the former is obviously preferrable for its length.
> 
> Matthias
> 
> 
>> -Original Message-
>> From: openssl-project  On Behalf Of 
>> Richard Levitte
>> Sent: Friday, July 24, 2020 8:34 AM
>> To: openssl-project@openssl.org
>> Subject: Re: API renaming
>> 
>> I'm fine with that, really.
>> 
>> I have a preference for OSSL_, but if we look through the source,
>> there's reason for either.  So far, we've majorly used OPENSSL_ for
>> things like feature macros (disabling macros, really), environment
>> variables, that sort of thing, while OSSL_ has become the primary
>> choice for new APIs ("less klunky", I think the judgement was in that
>> past discussion I keep referring to).
>> 
>> And yeah, I hear you from all the way around the planet, there are
>> some recent name choice that were made that give pause and are
>> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
>> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
>> I have no problem recognising that.  But, they are there, even though
>> only in master (*).  This is question of what we do going forward (a
>> yet unmerged PR with a new API is as good a target as any).
>> 
>> Cheers,
>> Richard
>> 
>> (*) I'm not sure I see master as something untouchable in this regard,
>> as the development is still not frozen (alpha), so I for one could
>> easily see a rename fest happening, should we decide for it.  That
>> must happen before we enter the beta phase, though...
>> 



Re: API renaming

2020-07-24 Thread SHANE LONTIS
I think the KDF and MAC got back ported also...

> On 24 Jul 2020, at 4:33 pm, Richard Levitte  wrote:
> 
> I'm fine with that, really.
> 
> I have a preference for OSSL_, but if we look through the source,
> there's reason for either.  So far, we've majorly used OPENSSL_ for
> things like feature macros (disabling macros, really), environment
> variables, that sort of thing, while OSSL_ has become the primary
> choice for new APIs ("less klunky", I think the judgement was in that
> past discussion I keep referring to).
> 
> And yeah, I hear you from all the way around the planet, there are
> some recent name choice that were made that give pause and are
> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
> I have no problem recognising that.  But, they are there, even though
> only in master (*).  This is question of what we do going forward (a
> yet unmerged PR with a new API is as good a target as any).
> 
> Cheers,
> Richard
> 
> (*) I'm not sure I see master as something untouchable in this regard,
> as the development is still not frozen (alpha), so I for one could
> easily see a rename fest happening, should we decide for it.  That
> must happen before we enter the beta phase, though...
> 
> On Fri, 24 Jul 2020 07:55:10 +0200,
> SHANE LONTIS wrote:
>> 
>> For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’  is not a particularly great 
>> rule either.
>> We should decide which one to use and stick to it.
>> 
>>> On 24 Jul 2020, at 3:20 pm, Richard Levitte  wrote:
>>> 
>>> A couple of points:
>>> 
>>> 1.  Quite a while ago, we (the team at the time) made a decision to
>>>   have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'.  It seems
>>>   that we never voted on it, though, but still.
>>> 
>>> 2.  The new RAND API hasn't been merged yet, so it's not like we're
>>>   renaming something that already exists.
>>> 
>>> So in terms of "it's just a prefix", OSSL_ would be just as suitable.
>>> It's a bit more blatantly "OpenSSL", though.
>>> 
>>> Cheers,
>>> Richard
>>> 
>>> On Thu, 23 Jul 2020 23:30:25 +0200,
>>> Tim Hudson wrote:
>>>> Placing everything under EVP is reasonable in my view. It is just a prefix 
>>>> and it really has no
>>>> meaning these days as it became nothing more than a common prefix to use.
>>>> 
>>>> I don't see any significant benefit in renaming at this point - even for 
>>>> RAND.
>>>> 
>>>> Tim.
>>>> 
>>>> On Fri, 24 Jul 2020, 1:56 am Matt Caswell,  wrote:
>>>> 
>>>>   On 23/07/2020 16:52, Richard Levitte wrote:
>>>>> On Thu, 23 Jul 2020 12:18:10 +0200,
>>>>> Dr Paul Dale wrote:
>>>>>> There has been a suggestion to rename EVP_RAND to OSSL_RAND.  This seems 
>>>>>> reasonable.  Would
>>>>   it
>>>>>> also make sense to rename the other new APIs similarly.
>>>>>> More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF 
>>>>>> respectively?
>>>>> 
>>>>> This is a good question...
>>>>> 
>>>>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
>>>>> APIs, they have a previous history of EVP APIs, through EVP_PKEY.  The
>>>>> impact of relocating them outside of the EVP "family" may be small,
>>>>> but still, history gives me pause.
>>>>> 
>>>>> RAND doesn't carry the same sort of history, which makes it much
>>>>> easier for me to think "just do it and get it over with"...
>>>> 
>>>>   I have the same pause - so  I'm thinking just RAND for now.
>>>> 
>>>>   Matt
>>>> 
>>>> 
>>> -- 
>>> Richard Levitte levi...@openssl.org
>>> OpenSSL Project 
>>> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
>>>  
>> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project 
> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LSCv_eY9cQfTVYkr1BXae4hxPy7nvs5sQQo1POAOF9yQFVSUvHdlaFUwYGSPI67pMw$
>  



Re: API renaming

2020-07-23 Thread SHANE LONTIS
For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’  is not a particularly great 
rule either.
We should decide which one to use and stick to it.

> On 24 Jul 2020, at 3:20 pm, Richard Levitte  wrote:
> 
> A couple of points:
> 
> 1.  Quite a while ago, we (the team at the time) made a decision to
>have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'.  It seems
>that we never voted on it, though, but still.
> 
> 2.  The new RAND API hasn't been merged yet, so it's not like we're
>renaming something that already exists.
> 
> So in terms of "it's just a prefix", OSSL_ would be just as suitable.
> It's a bit more blatantly "OpenSSL", though.
> 
> Cheers,
> Richard
> 
> On Thu, 23 Jul 2020 23:30:25 +0200,
> Tim Hudson wrote:
>> Placing everything under EVP is reasonable in my view. It is just a prefix 
>> and it really has no
>> meaning these days as it became nothing more than a common prefix to use.
>> 
>> I don't see any significant benefit in renaming at this point - even for 
>> RAND.
>> 
>> Tim.
>> 
>> On Fri, 24 Jul 2020, 1:56 am Matt Caswell,  wrote:
>> 
>>On 23/07/2020 16:52, Richard Levitte wrote:
>>> On Thu, 23 Jul 2020 12:18:10 +0200,
>>> Dr Paul Dale wrote:
 There has been a suggestion to rename EVP_RAND to OSSL_RAND.  This seems 
 reasonable.  Would
>>it
 also make sense to rename the other new APIs similarly.
 More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF 
 respectively?
>>> 
>>> This is a good question...
>>> 
>>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
>>> APIs, they have a previous history of EVP APIs, through EVP_PKEY.  The
>>> impact of relocating them outside of the EVP "family" may be small,
>>> but still, history gives me pause.
>>> 
>>> RAND doesn't carry the same sort of history, which makes it much
>>> easier for me to think "just do it and get it over with"...
>> 
>>I have the same pause - so  I'm thinking just RAND for now.
>> 
>>Matt
>> 
>> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project 
> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
>  



Re: OpenSSL version 3.0.0-alpha1 published

2020-05-01 Thread SHANE LONTIS
Thanks..

I will take a look.

Shane


> On 2 May 2020, at 2:20 am, Guido Vranken  wrote:
> 
> Reminder that in git master and 3.0.0, CAST5 gives the wrong output: 
> https://github.com/openssl/openssl/issues/11459 
> 
>  (this proof of concept was made before you moved CAST5 to liblegacy, so just 
> put OSSL_PROVIDER_load(nullptr, "legacy"); in there to make it work)
> 
> On Thu, Apr 23, 2020 at 4:30 PM OpenSSL  > wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
>OpenSSL version 3.0 alpha 1 released
>
> 
>OpenSSL - The Open Source toolkit for SSL/TLS
>https://www.openssl.org/ 
> 
> 
>OpenSSL 3.0 is currently in alpha.
> 
>OpenSSL 3.0 alpha 1 has now been made available.
> 
>Note: This OpenSSL pre-release has been provided for testing ONLY.
>It should NOT be used for security critical purposes.
> 
>Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
>as known issues are available on the OpenSSL Wiki, here:
> 
> https://wiki.openssl.org/index.php/OpenSSL_3.0 
> 
> 
>The alpha release is available for download via HTTPS and FTP from the
>following master locations (you can find the various FTP mirrors under
>https://www.openssl.org/source/mirror.html 
> ):
> 
>  * https://www.openssl.org/source/ 
> 
>  * ftp://ftp.openssl.org/source/ 
> 
> 
>The distribution file name is:
> 
> o openssl-3.0.0-alpha1.tar.gz
>   Size: 9530120
>   SHA1 checksum:  4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06
>   SHA256 checksum:  
> 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57
> 
>The checksums were calculated using the following commands:
> 
> openssl sha1 openssl-3.0.0-alpha1.tar.gz
> openssl sha256 openssl-3.0.0-alpha1.tar.gz
> 
>Please download and check this $LABEL release as soon as possible.
>To report a bug, open an issue on GitHub:
> 
> https://github.com/openssl/openssl/issues 
> 
> 
>Please check the release notes and mailing lists to avoid duplicate
>reports of known issues. (Of course, the source is also available
>on GitHub.)
> 
>Yours,
> 
>The OpenSSL Project Team.
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g
> RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk
> I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E
> cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8
> hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll
> Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F
> hIr11rxXNxtBRKUSlOUyJATZn0sV6g==
> =uRpM
> -END PGP SIGNATURE-



Re: CI build timeouts

2020-03-30 Thread SHANE LONTIS
Disabling memory leak checking doesn’t sound like a great idea..

> On 31 Mar 2020, at 1:09 am, Salz, Rich  wrote:
> 
> It’s time to disable that build, isn’t it?
> It’s timing out *AFTER AN HOUR*
>  
> From: Tomáš Mráz mailto:notificati...@github.com>>
> Reply-To: openssl/openssl 
>  >
> Date: Monday, March 30, 2020 at 9:51 AM
> To: openssl/openssl  >
> Cc: Subscribed  >
> Subject: Re: [openssl/openssl] [crypto/ec] blind coordinates in ec_wNAF_mul 
> for robustness (#11439)
>  
>> The CI failure doesn't really make sense to me.
> That's just an usual timeout unrelated to this PR.
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> ,
>  or unsubscribe 
> .



Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

2020-03-03 Thread SHANE LONTIS
FIPS_mode() and FIPS_mode_set() are functions that were used by the old FOM.

In OpenSSL_111 they were stripped down to do almost nothing
i.e:-

int FIPS_mode(void)  
{  
/* This version of the library does not support FIPS mode. */  
return 0;  
}

int FIPS_mode_set(int on)  
{
if (r == 0)  
return 1;

CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
return 0;  
}

The original plan for these API’s is listed in the design document for 3.0
i.e- the set would - set the global property and then do a fetch of a 
particular algorithm (this is problematic in itself since the algorithm may not 
exist for a 3rd party fips provider which could just implement a single 
algorithm).
And FIPS_mode() would just return true if the global property for fips was set.

This got some pushback and after discussion with a few other otc members - it 
was decided that the functions should be deprecated since it would be confusing 
to a user because there are multiple library contexts allowed each with their 
own fips property that can be changed at
any time.

This is done in https://github.com/openssl/openssl/pull/11075 
 and there is a related 
discussion in the comments.

This PR has also been rejected the deprecation and discusses
- FIPS_mode_set() function could be completely removed.
- FIPS_mode() - query using the default library context OR completely remove.

I have no issue with both functions being deleted as they no longer really mean 
the same thing as they did before.
Each library context has its own default properties - so querying FIPS_mode() 
could only return what the default library context’s fips properties are - it 
doesnt mean every library context is in fips mode, or even that the fips module 
is loaded. 
If the functions are removed then it may require a OMC vote since this could be 
viewed as a breaking change..

Does anyone have any thoughts on this?

Regards
Shane

Re: Deprecations

2020-02-21 Thread SHANE LONTIS

> On 22 Feb 2020, at 1:36 pm, Viktor Dukhovni  
> wrote:
> 
> But there's nothing like
> using a screwdriver to turn a screw, rather than banging it in with
> an all-purpose hammer!

If we are trying to tell users to not use the low level API’s, and then we go 
and use them everywhere in apps it is not really sending the correct message.
If we need to keep them - then they probably would need to be rewritten in 
terms of evp. (Or parse the parameters and pass them to another app call) :)). 
Either way its quite a bit of work.


> If you search internet, you will more than likely find the first
> ones. They are very easy. I have to look up at the manual page
> examples to know how to use genpkey.

Agreed. Being able to list all the pkey options from the app might be helpful 
here?

Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked?

2020-02-09 Thread SHANE LONTIS
With the new architecture changes there are quite a few new calls to

CRYPTO_UP_REF()
CRYPTO_DOWN_REF()

These methods return an int that is not being checked in lots of places.

This return value only seems to affect fallback code that calls 
CRYPTO_atomic_add (which can return 0 on lock or unlock failure)

SO the question is should we be checking this return value?


Note that not checking has resulted in a few assumptions in other code…
e.g the following function returns void.
 
/crypto/evp/keymgmt_lib.c: 165 in evp_keymgmt_util_cache_pkey()
159 }
160 
161 void evp_keymgmt_util_cache_pkey(EVP_PKEY *pk, size_t index,
162  EVP_KEYMGMT *keymgmt, void *keydata)
163 {
164 if (keydata != NULL) {
>>>CID 1458170:  Error handling issues  (CHECKED_RETURN)
>>>Calling "EVP_KEYMGMT_up_ref" without checking return value (as is done 
>>> elsewhere 4 out of 5 times).
165 EVP_KEYMGMT_up_ref(keymgmt);

NOTE: EVP_KEYMGMT_up_ref() just does an CRYPTO_UP_REF() call and always returns 
1.




Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS


> On 5 Jun 2019, at 12:34 pm, Richard Levitte  wrote:
> 
> Aside from the discussion below, if there's one thing I would like to
> change, it the double indirection for the _PTR data types.  The data
> types could still be used to indicate that the value isn't short
> lived, but could possibly change names to something like
> OSSL_PARAM_UTF8_CSTRING and OSSL_PARAM_OCTET_CSTRING (C for Constant).
> 
> On Wed, 05 Jun 2019 01:18:56 +0200,
> Dr Paul Dale wrote:
>> 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.
>> 
>> 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.
> 
> The reason why we have this issue is our base C language version
> choice.  C90 doesn't allow this construct:
> 
>int foo(whatever)
>{
>int haha = 0;
>const OSSL_PARAM params[] = {
>{ 'foo', OSSL_PARAM_INTEGER, , sizeof(haha), NULL },
>{ NULL, 0, NULL, 0, NULL }
>};
> 
>...
>}
> 
The above code is great in theory, but it looks like in practice we end up 
dynamically allocating in most cases anyway (via the construct_ methods).
And if this is the normal use case then OSSL_PARAMS could be made opaque and 
only accessed by API’s, then the argument about adding
extra types later on should also disappear?


> Because the compiler for that language version isn't allowed to emit
> code to use '' in an inititializer.  Newer C language versions
> allow this.
> 
> So while this is an issue for *us*, it isn't necessarily an issue for
> our users, all depending on what C language version they use.
> 
>> 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.
> 
> The design was not only to be able to have nice compile time
> initialization, but also to be able to pass the array as 'const
> OSSL_PARAM *', i.e. an indication to the recipient that the array
> itself should never be modified (less chance of compromise).  Maybe
> that's overly paranoid, but that was a line of thinking.
> 
>> 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:
>> 
>> 1. include a void * in the OSSL_PARAM structure that needs to be freed when 
>> the structure is
>> destroyed or
> 
> It's actually perfectly possible to do this today.  We already have
> this pointer, it's called 'data'.
> 
>> 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
> 
> My major concern with that, apart from having to modify the OSSL_PARAM
> items themselves¸ is that some time in the future, we will want to add
> another native type that's larger, which means we modify the size of a
> OSSL_PARAM.  It's a public structure, so that can't be treated
> lightly.
> 
> Also, with a union of native types, we're losing uniformity on MSB
> first platforms.  Having an exact 1:1 integer size match will be
> crucial, and that complicates the code quite a bit...  not to mention
> that we have a compatibility problem as soon as one end has a new
> native type in the union and the other doesn't.
> (one would imagine that simply using uintmax_t would cover all integer
> sizes apart from BIGNUM, but the potential size change of that type
> with newer compilers make such a choice precarious)
> 
>> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
>> needs to be freed.
> 
> By whom?  The owner of the array should be in complete control of
> what's needed already, so should be able to know what needs being
> deallocated or not.
> 
> If you're thinking that the receiving side should free certain values,
> then you need to pass a pointer to the routine to be used to free the
> value rather than just a flag.
> 
>> 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.
>> 
>> For the most part, the receiver side APIs seem reasonable.  It is the owning 
>> side that has the
>> complications.
>> 
>> 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.
>> 
>> 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).
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Cryptographer | Network Security & Encryption 
>> Phone +61 7 3031 7217
>> 

Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
I presume the reference approach was used to solve the issue of who actually 
owns/free's the data.
 

> On 5 Jun 2019, at 9:18 am, Dr Paul Dale  wrote:
> 
> 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.
> 
> 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.
> 
> 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:
> 
> 1. include a void * in the OSSL_PARAM structure that needs to be freed when 
> the structure is destroyed or
> 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
> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
> needs to be freed.
> 
> 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.
> 
> 
> For the most part, the receiver side APIs seem reasonable.  It is the owning 
> side that has the complications.
> 
> 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.
> 
> 
> 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).
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
>> On 4 Jun 2019, at 11:26 pm, Richard Levitte > > wrote:
>> 
>> On Tue, 04 Jun 2019 14:57:00 +0200,
>> Salz, Rich wrote:
>>> 
>>> 
   Part of the idea was that this would be a means of communication
>>>between application and provider, just like controls are with
>>>libcrypto sub-systems.
>>> 
>>> 
>>> I can probably find the email thread (or maybe it was a GitHub
>>> comment on my proposal for params), where you said, quite
>>> definitively, that this was *not* a general-purpose mechanism but
>>> rather a way to expose the necessary internals for opaque objects
>>> like RSA keys.
>> 
>> Either I misunderstood what you said at the time, or you misunderstood
>> what I said...  there's definitely a disconnect here somewhere.
>> 
>> What I wonder is why it should be exclusively only one of those
>> options?
>> 
>> Either way, the OSSL_PARAM is defined publically and openly (i.e.
>> non-opaque), and we currently have the following functions in the
>> public API:
>> 
>>EVP_MD_CTX_set_params
>>EVP_MD_CTX_get_params
>>OSSL_PROVIDER_get_params
>> 
>> I fully expect that more will come.  I have a branch where I've
>> EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if
>> EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before
>> long (I'm actually rather surprised they haven't already), and I'm
>> absolutely sure we will see similar functions for asymmetric
>> algorithms.
>> 
>>> What changed your mind?
>>> 
>>> Perhaps not surprisingly, I agree with Shane's assessment and am
>>> strongly opposed to the project foisting this on everyone at this
>>> time.  @DavidBen, your thoughts?
>> 
>> Maybe we're reading differently, I didn't see Shane being opposed to
>> parameter passing in this way per se, just the exact form of the
>> OSSL_PARAM structure, which is different.
>> 
>> Cheers,
>> Richard
>> 
>> -- 
>> Richard Levitte levi...@openssl.org 
>> OpenSSL Project http://www.openssl.org/~levitte/ 
>> 


Re: OSSL_PARAMs

2019-06-04 Thread SHANE LONTIS
The controls are easier to understand and use currently.
The advantage of params is that you can batch them, so that the order no longer 
matters during setup (e.g- I need to set EVP_MD first).

The params are not being used in anger yet.
My main problem with the params is that no data is set into them - only 
pointers to the data blob.
I find this to be a confusing interface which hurts my (tiny) brain (especially 
with types like strings)
I would prefer base types (like int to just be embedded in the set data - even 
if that meant allocs are needed).
My concern is that is the end user is supposed to use what we have currently, 
there are going to be many issues.

Shane

> On 4 Jun 2019, at 4:12 pm, Dr Paul Dale  wrote:
> 
> A question for the committers and beyond.
> 
> Should the OSSL_PARAM concept be used for more than just the libcrypto ⇿ 
> provider interface?
> 
> The one that springs to mind is a more general form of the various ctrl 
> calls, there are some string ctrl calls that attempt to do the same thing in 
> a less structured manner.
> 
> 
> Thoughts?
> 
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 



Re: proposed change to committers policy

2019-05-24 Thread SHANE LONTIS
It doesn’t stop us both reviewing a PR. That doesn’t mean we both need to 
approve.


> On 24 May 2019, at 7:21 pm, Matthias St. Pierre 
>  wrote:
> 
> 
> 
> >   In considering approvals, the combined approvals must come
> >   from individuals who work for separate organisations.
> >   This condition does not apply where the organisation is the
> >   OSF or OSS.
> 
> 
> IMHO an important clarification needs to be made: The rule should not be about
> _prohibiting_ double approvals. It should only be about _counting_ them.
> I would not deprive people of the right to state their opinions.
> 
> Also, if Shane has already approved, then Pauli should still have the right
> to approve, since his approval counts as OMC approval and Shane's not.
> 
> How about using a formulation like the following?
> 
> In considering approvals, approvals from individuals being
> employed by the same third party company or organization should
> be counted as a single approval. If one of the individuals is
> an OMC member, the combined approval counts as an OMC approval.
> This condition does not apply where the organisation is the
> OSF or OSS.
> 
> 
> An editorial comment: I think that the amendmend should be made inside the
> unordered list, not following it.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_web_blob_master_policies_committers.html-23L72-2DL78=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk=DYHGYucybgbeMHQn9pS8SBhh_dvJkYrDgKu9gU2l9H4=jT3VTidhpkkMAwUuiu_JgqW9mBpD4PP-3Qc8D3KZDdU=
> 
> Apart from that: Tim, could you (or someone else of the OMC) please raise a PR
> for your proposal? That would make it easier to discuss the details.
> 
> Matthias
> 
>