Re: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

2016-07-21 Thread Brian Smith 
Brian Smith via RT  wrote:

> Finally, as I mentioned on the mailing list, it seems the function is_zero
> is missing a comparison of the last limb in the 32-bit case.
>

And of course, when I said "is_zero" I meant "is_one":
https://github.com/openssl/openssl/blob/aa6bb1352b1026b20a23b49da4efdcf171926eb0/crypto/ec/ecp_nistz256.c#L226



-- 
https://briansmith.org/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

2016-07-21 Thread Brian Smith via RT 
Brian Smith via RT  wrote:

> Finally, as I mentioned on the mailing list, it seems the function is_zero
> is missing a comparison of the last limb in the 32-bit case.
>

And of course, when I said "is_zero" I meant "is_one":
https://github.com/openssl/openssl/blob/aa6bb1352b1026b20a23b49da4efdcf171926eb0/crypto/ec/ecp_nistz256.c#L226



-- 
https://briansmith.org/

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4621] BUG: nistz256 point addition check for a = +/-b doesn't work for unreduced values

2016-07-21 Thread Brian Smith via RT 
I verified with the authors of the nistz256 code that all the arithmetic is
done mod P256 (P), but the results might be unreduced if they are less than
2**256. Thus, all the arithmetic must handle the cases where its inputs are
in the range [0, 2**256 - 1], not just [0, P). And, it must deal with the
cases where some values have multiple representations. For example, the
value 0 can be represented as either 0 or P + 0, 1 can be represented
either as 1 or as P + 1, etc.

The nistz256 code contains code that looks like this:

  if (is_equal(U1, U2) && !in1infty && !in2infty) {
if (is_equal(S1, S2)) {
...
}
  }

This code only works for values that have one representation; it doesn't
work for all values. For example, consider U1 == 1, U2 = P + 1. Then,
is_equal(U1, U2) returns false, but in fact U1 == U2 (mod P). Thus, we
should run the code for the exceptional case (doubling or setting to the
point at infinity), but actually we just keep going with a normal addition.

You can see that the code in ecp_nistp256 and ecp_nistp224 such as
`is_zero` handles this correctly by considering both representations of 0:
0 and P + 0.

To fix this, a constant-time conditional subtraction of P should be done on
U1 and U2, and a conditional subtraction should also be done on S1 and S2.
I discussed this with some other people familiar with the code and they
agree that this seems to be a good way to do it.

Note again that it is possible for the value 0 to be represented as either
0 or as P + 0. This brings into question whether is_zero is correct,
because it doesn't consider P to be zero. Here there was some disagreement
about whether it is necessary to check for P. I personally think that it is
safer to check for both 0 and P like the nistp256 code does, because I it
is hard to make a proof that the values cannot be P.

Not also again that the value 1 can be represented as 1 or as P + 1. Thus,
the statement Z_is_one = is_one(...); appears to also be wrong, or at least
not obviously correct.

Finally, as I mentioned on the mailing list, it seems the function is_zero
is missing a comparison of the last limb in the 32-bit case.

Unfortunately, I don't have any test vectors for triggering any bugs that
would serve as a basis of regression tests; these were found from reading
the code.

Cheers,
Brian
-- 
https://briansmith.org/

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

2016-07-21 Thread David Woodhouse via RT 
(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire — because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

2016-07-21 Thread David Woodhouse 
(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire — because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org #4602] Missing accessors

2016-07-21 Thread Kurt Roeckx via RT 
On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote:
> Hi Richard, Mattias, others,
> 
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.

Is there a way to recoginize those non-RFC3820 proxies?



Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4602] Missing accessors

2016-07-21 Thread Richard Levitte via RT 
On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > I guess having a more restrictive accessor that only sets the
> > > EXFLAG_PROXY bit could work. I suggested the more general solution
> > > of
> > > having set/clear accessors for arbitrary flags since it was - well
> > > more
> > > general.
> >
> > So let me ask this in a different manner, does OpenSSL 1.1 still not
> > set the
> > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > That may be
> > worth a bug report of its own.
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
>
> The answer to this is related to Mischa's reply, which unfortunately
> was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
> below. As indicated in the answer, setting the EXFLAG_PROXY allows
> handling non-RFC proxies in OpenSSL.
>
> mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > Hi Richard, Mattias, others,
> >
> > I agree with you that it would be nice if OpenSSL could figure out
> > itself whether a cert needs to be treated as a proxy, but currently
> > that
> > doesn't work reliably as far as I know.
> > The flag is certainly needed in the case of non-RFC3820 proxies, also
> > known as legacy proxies. Unfortunately these are still very widely
> > used
> > (majority of the proxies actually) and hence our code must be able to
> > handle them correctly.
> >
> > Best wishes,
> > Mischa Sallé
> >

Ok... From looking at the voms code that was linked to earlier, I can see that
legacy proxy certs are recognised by an older OID (called PROXYCERTINFO_V3 in
the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions in that
version, whether they are critical or not and so on, that I can reach? Or is
the OID the only actual difference? If it's easy enough (and it currently does
look quite easy), I can certainly see adding some code in OpenSSL to recognise
those...

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.1 release being delayed

2016-07-21 Thread Matt Caswell 


On 21/07/16 09:56, Christian Hägele wrote:
> Am 25.06.2016, 00:27 Uhr, schrieb Matt Caswell :
> 
>> The current thinking is Thursday 7th July, although that is not set in
>> stone as it depends on what happens between now and then. We don't
>> currently have any plans for a beta 3, although again that could change.
> 
> 7th of July was 2 weeks ago.
> Are there any news on the updated release-plans? I did not find any
> updated information on this.

We still have a number of issues that need to be resolved before we can
release. We don't yet have a new date agreed. The best I can offer at
the moment is "August". We're all working hard to try and bring it in as
soon as possible.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.1 release being delayed

2016-07-21 Thread Christian Hägele 

Am 25.06.2016, 00:27 Uhr, schrieb Matt Caswell :


The current thinking is Thursday 7th July, although that is not set in
stone as it depends on what happens between now and then. We don't
currently have any plans for a beta 3, although again that could change.


7th of July was 2 weeks ago.
Are there any news on the updated release-plans? I did not find any  
updated information on this.


Regards,

Christian

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4620] OCSP_basic_verify() question/comment

2016-07-21 Thread Salz, Rich via RT 

> OCSP responses do not seem to include the intermediate certificates so they
> have to be acquired in other ways.   I have been doing this and adding them
> to the certificate stack handed to OCSP_basic_verify().

Perhaps adding them to X509_STORE or STORE_CTX directly?

> I am relatively new to this so I may be incorrect; however, it seems to me
> that the certificates in the cert argument should be added to the
> X509_STORE_CTX.

If you need to add certificates to validate a chain, it seems safer to 
explicitly add them to the store, not implicitly.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4620
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

2016-07-21 Thread Mattias Ellert via RT 
ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > I guess having a more restrictive accessor that only sets the
> > EXFLAG_PROXY bit could work. I suggested the more general solution of
> > having set/clear accessors for arbitrary flags since it was - well
> > more
> > general.
> 
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
> 
> --
> Richard Levitte
> levi...@openssl.org
> 

The answer to this is related to Mischa's reply, which unfortunately
was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
below. As indicated in the answer, setting the EXFLAG_PROXY allows
handling non-RFC proxies in OpenSSL.

mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> Hi Richard, Mattias, others,
> 
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.
> 
> Best wishes,
> Mischa Sallé
> 

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4620] OCSP_basic_verify() question/comment

2016-07-21 Thread Page, Greg via RT 
Hello!


I have been using openssl to get OCSP status for a certificate and I ran across 
an interesting case.


OCSP responses do not seem to include the intermediate certificates so they 
have to be acquired in other ways.   I have been doing this and adding them to 
the certificate stack handed to OCSP_basic_verify().


However, I have noticed that these certificates are not used in creating a 
certificate chain back to a root CA because they are not added to the 
X509_STORE_CTX that is sent to X509_verify_cert() and 
X509_STORE_CTX_get1_chain().


I am relatively new to this so I may be incorrect; however, it seems to me that 
the certificates in the cert argument should be added to the X509_STORE_CTX.


What are your thoughts?


Thanks,

Greg


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4620
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev