This vote is now closed.
Viktor's vote was a little unclear but I interpreted it as a -1 in
recording the votes.
accepted: yes (for: 5, against: 4, abstained: 1, not voted: 1)
Matt
On 03/11/2020 12:11, Matt Caswell wrote:
> Background to the vote:
>
> The OTC meeting today discussed the pr
I will only answer what I see as new points in your last email, to
avoid repeating ourselves.
Validity of a serialized key:
- ASN.1 validity says little about the validity of the key, as ASN.1
cannot enforce limits on the private scalar range
- validity as a serialized EC key requires that in addi
This is what I read:
- the key in p256_invalid.pem is invalid in other ways than merely the
lack of the public key in the file.
(the public key is *not* lacking in run-time in this example, since
d2i_ECPrivateKey() autogenerates it, which happens before it's
checked or used)
- you confirm
The issue with that key is that the secret scalar `k` is equal to `n`
(where `n` is the order of the generator point `G`), while for EC keys
the validity range is `1 <= k < n`.
If the scalar `k` is equal to `n`, it means that the associated pubkey
is `k*G` = `n*G` = `0*G mod n` = `P_infinity`.
The
It exists in master but not in 1.1.1 or previous: the incomplete EVP_PKEY
object of #12612 in previous versions would have failed validation, where
its correctness as a math entity and as a programming object is tested.
That is why I am baffled by the use of "regression" to describe this issue,
an
Er, Nicola, I'm unsure how that endless loop has anything to do with
the presence or the absence of a public key, as it happens in
ossl_ecdsa_sign_sig(), which doesn't even look at the public key, at
all.
Your check does say that the key you have there is invalid, but that
would rather be because
On Wed, 11 Nov 2020 23:34:53 +0100,
Nicola Tuveri wrote:
>
> By design the consistency checks and validation checks are omitted
> unless these functions are called, and there is no
> EVP_PKEY_private_check.
Just a small point, this is in master:
$ grep private_check include/openssl/evp.h
On Sun, 15 Nov 2020 22:36:54 +0100,
Kurt Roeckx wrote:
>
> On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote:
> >
> > The proposal discussed was that while relaxing the conceptual model,
> > most of the existing implementations would still require both. The EC
> > implementation would
>> > The private key is a random or pseudo-random 256-bit integer.
>> > How do you propose to "validate" that?
>>
>> For ECDSA it's not a a random or pseudo-random 256-bit integer: it's a
>> random or pseudo-random integer `k`, with `1 <= k < n`, not all
>> 256-bit integers fit into this definition
On Thu, 12 Nov 2020 at 10:33, Nicola Tuveri wrote:
>
> >8
>
> > The private key is a random or pseudo-random 256-bit integer.
> > How do you propose to "validate" that?
>
> For ECDSA it's not a a random or pseudo-random 256-bit integer: it's a
> random or pseudo-random integer `k`, with `1 <= k <
On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote:
>
> 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 beha
On Thu, Nov 12, 2020 at 11:42 AM Dick Franks wrote:
>
> On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote:
>>
>>
>> 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 s
On Wed, 11 Nov 2020 at 14:14, Nicola Tuveri wrote:
>
> 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 o
Usually the labs provide assurances on the key generation and the
other cryptographic operations, including validation, but have special
provisions to avoid providing assurances on key serialization and
deserialization.
This seems particularly true in the context of the FIPS validation for
OpenSSL
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 oper
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
As I said in the OTC meeting, I agree we should change the conceptual model
to not require a private key to be a super-set of a public key; however I
do not think we should introduce key-type specific behaviour in this area -
i.e. if it makes sense to change the model then it should apply equal
0
> -Original Message-
> From: openssl-project On Behalf Of Matt
> Caswell
> Sent: Tuesday, November 3, 2020 1:11 PM
> To: openssl-project@openssl.org
> Subject: OTC VOTE: EVP_PKEY private/public key components
>
> Background to the vote:
>
> The OTC meeting today discussed the problem
18 matches
Mail list logo
