On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote:
> On 1/14/16, 13:56 , "Hubert Kario" wrote:
> >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote:
> >> If you already know what Dr. Henson explained in the quoted emails
> >> -
>
Yes, and I can live with this update.
I still think it would be nice to inform the user of what to expect in the
(unlikely but possible) case when his data is not an output of some
cryptographic hash function.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
On Friday 15 January 2016 14:03:33 Blumenthal, Uri - 0553 - MITLL wrote:
> Yes, and I can live with this update.
Submitted as https://github.com/openssl/openssl/pull/554
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o.,
Yes you are correct. But... For RSA the max size cannot be greater than the
modulus, and while I agree that usually it would be less, in general it doesn't
have to be, with no negative impact on security when data to be signed is large
enough to leave no room for padding. For ECDSA truncating
Hubert Kario wrote:
> The bug is still present in version tagged as OpenSSL_1_1_0-pre1
>
> Moreover I've verified that the miTLS implementation[1] shows expected
> behaviour - it accepts the interleaved application data everywhere but
> between CCS and Finished.
I don't know if that is feasible,
I wanted to report a behavior of the OpenSSL API that I find at least
highly unusual and unexpected and I suggest to change.
It's regarding these functions to set curve coordinates:
EC_POINT_set_affine_coordinates_GFp
EC_POINT_set_compressed_coordinates_GFp
It is possible to pass them a
The attached patch provides documentation of some of the currently
undocumented speed options.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff
On Wed, 16 Dec 2015 16:01:02 +
"Salz, Rich" wrote:
> > I would recommend and find it generally a cleaner approach if the
> > curve point setting functions would reject both invalid points and
> > point coordinates larger than p.
>
> Certainly out-of-range. Not sure
> All right, can the above be committed and any other source-backwards-
> compatible behaviour ?
>
> This will help API developers a lot.
It was done and is part of the yesterday's alpha release.
___
openssl-dev mailing list
To unsubscribe:
Code inspection suggests that when running "openssl dhparam -check -out foo
2048", the safety of the generated prime is only indicated via stdout.
I suggest one of three safety improvements here, in order of what I believe to
be decreasing safety:
(1) Regardless of whether the "-check" flag is
This is according to our interpretation of "type opacity", meaning that the
type name is available but not its content. "Data hiding" is another way to put
it. This means that there will be a need to adapt, stack allocated
EVP_CIPHER_CTX is no longer allowed, but there are functions to allocate
Hi,
My openssl version is OpenSSL 1.1.0-pre2-dev xx XXX
But when calling DTLSv1_2_client_method() , it shows compiler error as
undefined reference to DTLSv1_2_client_method()
Can you please look at this matter ?
___
openssl-bugs-mod mailing list
Hi OpenSSL Devs,
I have this bug fix for a broken wildcard matching on punycode domain
in OpenSSL. Specifically, the current implementation actually can't
match "www.xn--foobar.com" against a certificate using SAN
"*.xn--foobar.com". I filed a issue on github too.
The EC_POINT_* API functions accept invalid curve points and don't do
point verification.
Invalid curve points are one of the major implementation pitfalls in
ECC and can lead to attacks [1]. OpenSSL properly validates points in
the _oct2point functions, but I still find this risky. This looks
hello,
apologies if I am missing something here.
There seems to be an inconsistency in 1.1.0-pre2 (didn't check -pre1).
EVP_CIPHER_CTX is typedef'd in ossl_typ.h like this:
typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX;
but struct evp_cipher_ctx_st isn't exposed any longer (it used to
> On Jan 15, 2016, at 10:32 AM, Zi Lin via RT wrote:
>
>
Yes, this will get fixed. Thanks.
--
Viktor.
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe:
In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25 +0100,
Rainer Jung said:
rainer.jung> Hi,
rainer.jung>
rainer.jung> the list of downloadable files on http://openssl.org/source/
contains
rainer.jung> pre1 *and* pre2 files for 1.1. Furthermore
On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte"
wrote:
>In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25
>+0100, Rainer Jung said:
>
>rainer.jung> In addition one
Hi,
the list of downloadable files on http://openssl.org/source/ contains
pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above pre2.
IMHO pre2 is what people should test and pre1 is no longer entitled to
be listed on that page. So I suggest to remove pre1 from the list.
I don't
In message on Fri, 15 Jan 2016 18:38:32 +,
"Blumenthal, Uri - 0553 - MITLL" said:
uri> On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte"
uri> wrote:
uri>
uri>
> On Jan 15, 2016, at 10:32 AM, baldu...@units.it via RT
> wrote:
>
> This seems to be the reason why trying to build openssh-7.1p2 (with
> -DOPENSSL_API_COMPAT=0x1000L) fails with:
>
>In file included from ssh_api.h:26:0,
> from ssh_api.c:21:
>
> On Jan 15, 2016, at 10:32 AM, baldu...@units.it via RT
> wrote:
>
> This seems to be the reason why trying to build openssh-7.1p2 (with
> -DOPENSSL_API_COMPAT=0x1000L) fails with:
>
>In file included from ssh_api.h:26:0,
> from ssh_api.c:21:
>
e_os.2 line 327::
# if !defined(inline) && !defined(__cplusplus)
Should this be:
# if !defined(ossl_inline) && !defined(__cplusplus)
The purpose of this section is to end up with a good definition for ossl_inline
If some preceding header file (and I have run across this) does a #define
On Fri, Jan 15, 2016 at 03:32:12PM +, Zi Lin via RT wrote:
> I have this bug fix for a broken wildcard matching on punycode domain
> in OpenSSL. Specifically, the current implementation actually can't
> match "www.xn--foobar.com" against a certificate using SAN
> "*.xn--foobar.com". I filed a
req.c (and many of the other apps) appear to have lost the ability to use an
engine.
The attached diff is against the github.com verison using Tag OpenSSL_1_1-pre2
In the req_options[] table:
OPT_KEY is set to "S" so pre- checking of the parameters does not drop the
string passed to the
Building 1.1.0-pre2 on Solaris Sparc I get compilation errors, e.g.
e_des.c: In function 'des_init_key':
e_des.c:250:23: error: dereferencing pointer to incomplete type
int mode = ctx->cipher->flags & EVP_CIPH_MODE;
The following patch fixes them:
Index: crypto/evp/e_camellia.c
---
Doug, could you please take a look at PR #548 (or is it #549)? It also
addresses this KEY_FORM issue.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
Original Message
From: deeng...@gmail.com via RT
Sent: Friday, January 15, 2016 17:10
Reply To: r...@openssl.org
On Thu, Jan 14, 2016 at 03:35:48PM -0500, Viktor Dukhovni wrote:
> Thanks for the prompt error report. If you're willing to share your
> test chains, and if it is likely to be not too difficult to include
> them with the OpenSSL bundled tests, that might be worth looking into.
All the test case
28 matches
Mail list logo