> I’m not sure us mere mortals can add a label to a PR...
> tshort> --
> tshort> -Todd Short
> tshort> // tsh...@akamai.com
> tshort> // "One if by land, two if by sea, three if by the Internet."
> tshort>
> tshort> On Feb 27, 2017, at 5:04 AM, Emil
One if by land, two if by sea, three if by the Internet."
>
> On Feb 27, 2017, at 5:04 AM, Emilia Käsper <emi...@openssl.org> wrote:
>
> Hi OpenSSL developers!
>
> We’re always looking for ways to improve code quality and pay our
> technical debt. This week we thought
Hi OpenSSL developers!
We’re always looking for ways to improve code quality and pay our technical
debt. This week we thought we’d run a little experiment.
We declare this Tuesday (Feb 28th) Code Health Tuesday. We’ll be setting
some time aside to do cleanups in the codebase. The theme is
Done in 1e2012b7ff4a5f12273446b281775faa5c8a1858, thanks for the nudge.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4242
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Merge RT4241 here as these are best handled together.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Resolving, this has been merged.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4506
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
X509_REQ_to_X509 returns a newly allocated X509 structure.
If you believe that it leaks somewhere else, then please reopen this ticket
with fully self-contained code, and a trace (e.g., from valgrind) showing where
the leak happens.
Emilia
--
Ticket here:
Merged. (Please reopen if you think we should also follow up in the other
direction.)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
While we're at this, shouldn't we then also check the length in oct2priv? (And
either reject or reduce mod n.) Afaics it accepts arbitrary BNs currently,
which means some keys can be parsed but cannot be re-encoded?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
Please log in
FYI for easier use, this patch now lives at
https://github.com/google/openssl-tests, rebased against BoringSSL latest
(thanks David!) and OpenSSL-1.1.0-pre4 (Beta 1). I've also checked in a log
from Beta 1.
Cheers,
Emilia
On Thu, Mar 10, 2016 at 4:33 PM David Benjamin
Returning to the issue at hand:
https://github.com/openssl/openssl/pull/851
On Fri, Mar 11, 2016 at 7:24 PM Erik Forsberg wrote:
> add Solaris to the platforms that are not at beta-level yet.
> Richard Levitte and myself are helping each other out though, so we should
> be close
Yep, there is no need to clean up early here (we don't guarantee that errored
calls leave everything in a pristine unmodified state). Plus this does indeed
forget to zero the pointer. Closing. Thanks for submitting, though, and thanks
David for the review!
--
Ticket here:
On Fri, Mar 4, 2016 at 11:00 PM Viktor Dukhovni <openssl-us...@dukhovni.org>
wrote:
>
> > On Mar 4, 2016, at 3:57 PM, Emilia Käsper <emi...@openssl.org> wrote:
> >
> > I've updated the pull to do a much more substantial cleanup.
>
> What will @STRE
I've updated the pull to do a much more substantial cleanup.
On Thu, Mar 3, 2016 at 6:16 PM Emilia Käsper <emi...@openssl.org> wrote:
> Hm, I think that I actually agree. But David's done enough, so I'll have a
> look myself.
>
> On Thu, Mar 3, 2016 at 5:33 PM Blumenthal,
On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT wrote:
> > If the other EVP ciphers universally allow this then I think we must
> treat this
> > as a bug, because people may be relying on this behaviour. There is also
> > sporadic documentation in lower-level APIs (AES
enssl.org on behalf of ha...@hboeck.de> wrote:
>
> >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper <emi...@openssl.org>
> >wrote:
> >>https://github.com/openssl/openssl/pull/783
> >
> >This is different from what I had in mind.
> >...
> >I would arg
https://github.com/openssl/openssl/pull/783
Courtesy of David Benjamin.
On Thu, Mar 3, 2016 at 4:34 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> +1
>
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network.
> Original Message
> From: Hanno Böck
>
If the other EVP ciphers universally allow this then I think we must treat this
as a bug, because people may be relying on this behaviour. There is also
sporadic documentation in lower-level APIs (AES source and des.pod) that the
buffers may overlap.
If it's inconsistent then, at the very least,
We cleaned this up a little:
- crypto/conf/ssleay.cnf was obsolete and is gone from the master branch.
- the req app now uses 2048 bits as a default if no other defaults are given.
ssleay.txt is already gone from the master branch, and the test/ ones are used
in tests.
Cheers,
Emilia
--
Fixed in master now, commit b1413d9bd9d823ca1ba2d6cdf4849e635231
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1.1.0 now defaults to no compression: dc5744cb78da6f2bcafeeefe22c604a51b52dfc5.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Resolved in ba2de73b185016e0a98e62f75b368ab6ae673919 for master (1.1.0). This
isn't really a bug so we won't be backporting to stable branches, though.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This was rejected by the team.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1.0.1m predates Logjam. We changed DH key generation to use 2048 bits by
default in OpenSSL 1.0.1n which is the first 1.0.1 release after.
The default_bits in apps/openssl.cnf is a sample certificate request
configuration and isn't really related to Logjam. But we changed it as well as
other key
To close off this thread: OpenSSL will not be making any changes.
The team voted on moving a set of algorithms to maintenance mode, and
removing the corresponding assembly implementations from libcrypto, but the
vote did not pass.
Emilia
On Fri, Nov 27, 2015 at 10:19 AM, Tim Hudson
On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote:
> > MD2 - (The argument that someone somewhere may want to keep verifying old
> > MD2 signatures on self-signed certs doesn't seem like a compelling enough
> > reason to me. It's been disabled by default since OpenSSL
n, Nov 16, 2015 at 2:21 PM, Hubert Kario <hka...@redhat.com> wrote:
> On Friday 13 November 2015 14:40:33 Emilia Käsper wrote:
> > Hi all,
> >
> > We are considering removing from OpenSSL 1.1 known broken or outdated
> > cryptographic primitives. As you may know the
or any of the other algorithms,
please let us know!
Thanks,
Emilia
On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario <hka...@redhat.com> wrote:
> On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
> >
>
Hi all,
We are considering removing from OpenSSL 1.1 known broken or outdated
cryptographic primitives. As you may know the forks have already done this
but I'd like to seek careful feedback for OpenSSL first to ensure we won't
be breaking any major applications.
These algorithms are currently
Thanks Martin. (Re-closing the ticket.)
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Given OpenSSL's eternal type confusion, this check is meant to trap callers
that get an error return (typically -1) from some API returning signed values
and pass that on to PACKET_buf_init as a size_t. For example, ssl3_get_message
returns a long to signal buffer length, and that makes me
Curves aren't negotiated with the ciphersuite, but rather via a separate
extension. Since OpenSSL 1.0.2, there are
SSL_CTX_set1_curves and SSL_CTX_set1_curves_list to configure supported curves:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_ecdh_auto.html
OpenSSL 1.1 also has a security
openssl-1.0.1h-cmp isn't an official OpenSSL version. You should seek help
with whoever provides this library for you.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Rejecting - SCSV is not a TLS extension.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This was fixed in January: 6fa805f516f5a6ff3872f1d1014a3dc9de460b99
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This sounds like an application problem.
1) Did you recompile your source? 0.9.7 and 1.0.1 are not binary-compatible.
2) The certificate hash format has changed between 1.0.1 and 0.9.7, which could
explain why the lookup no longer works:
https://www.openssl.org/docs/manmaster/apps/rehash.html
If
Nope, not doing anything wrong. makedepend is bust and can't find the headers.
Our clang and OS/X configurations were a bit off - I've changed them to use
clang for 'make depend' as well when clang is the compiler, see commit
c97c7f8d53dda12f4fda24fc7542281999df97f6.
Cheers,
Emilia
Thanks for the report. This has now been addressed in 1.0.1+, see commit
bfc19297cddd5bc2192c02c7f8896d804b0456cb.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Closing, not an OpenSSL defect.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I'm afraid we can't tell from your report whether the bug is in OpenSSL or in
your application code. We need a reproducible report - for example, a
standalone code snippet, or a sample input to the openssl command-line tool.
Cheers,
Emilia
___
Closing, because it's not an OpenSSL defect, but feel free to continue the
discussion on openssl-users.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Tracking ticket - if anyone has any concerns, please voice them now.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
You're spot on, thanks for the report! The fix ended up being slightly
different, but this is now fixed in 1.0.1+.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Wow, thanks for the thorough report. This was so broken that I had to go for a
pretty major rewrite. Please take a look at commits
3cdd1e94b1d71f2ce3002738f9506da91fe2af45 and
b785504a10310cb2872270eb409b70971be5e76e. (Also cherry-picked to 1.0.2 and
1.0.1.)
All your test cases now pass so I'm
Thanks Rob! Resolving.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Fixed now in OpenSSL 1.0.1+, thanks for the report!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
In the is_sslv3 case, the header length is recomputed to be large enough.
I also note that we've recently added a sanity check to make this explicit, see
commit
29b0a15a480626544dd0c803d5de671552544de6
Sorry that we didn't acknowledge your report!
Cheers,
Emilia
CVE-2014-0224 was fixed in 1.0.1h.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It's been fixed.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Whatever it was, it's no longer reproducible.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
How prophetic! We now require 768 and will do another bump to 1024 in the near
future, so I'm resolving this ticket.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
No evidence that it's an OpenSSL bug. You can try openssl-users@ though I'm
afraid there's not enough detail to resolve the problem there either.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We didn't hear back and there's not enough info to repro; closing.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Chain building is complicated, because the issuance graph is complicated: certs
get recertified, cross-signed, etc. Different clients have different trust
stores, and will build different paths.
We recently improved OpenSSL chain building to try more paths:
see
As Rich said, this is according to ASN.1 DER spec. Serial numbers are integral,
and you need 17 bytes to represent this serial number in two's complement form.
___
openssl-dev mailing list
To unsubscribe:
Probably same as https://rt.openssl.org/Ticket/Display.html?id=2968. We
improved this.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
OpenSSL attempts to load the master/default conf before diving into the
subcommand and overriding the conf with the config in -config. It'll bail when
it can't read the file, but only warn if the file does not exist.
This seems wrong, and is a regression compared to 0.9.8, so I'm going to leave
OpenSSL has SSL_SESSION_get_id since 0.9.8, so resolving this ticket just
before its 11th anniversary.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It's been 5 years and we never heard back with more details, so rejecting this
ticket. I suppose it could be CVE-2014-3509, though I can't tell.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We can't help you with legal matters:
https://www.openssl.org/docs/faq.html#LEGAL1
Please note that this tracker is for bug reports.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
The fix was committed in 995207bedcc58f2fa1bd7c460ee530b92c7dfbfe, so I think
we can resolve this ticket.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
There doesn't seem to be an open action item for OpenSSL here, so resolving
this ticket.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hi Pavel,
I'm closing this ticket because there isn't sufficient detail to conclude that
it's an OpenSSL bug, and not a problem with the plugin, or your environment.
You can try asking for help on openssl-users@, though it looks more like a
question for the Miranda NG community.
Emilia
Hm.
You pass in a NULL key. The docs say that a NULL key indicates that we should
reuse the existing key. With a new CTX, there is nothing to reuse, so it seems
reasonable that the call should fail.
If you actually wanted to set up the context with an empty key, you'd have to
pass in a dummy key
On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox <waywardg...@google.com> wrote:
> On Tue, Sep 1, 2015 at 2:50 PM, Emilia Käsper <emi...@openssl.org> wrote:
>
>> It's not quite clear to me why you'd have to resend parameters on
>> resumption. After all, they are de
I am afraid that there is not enough information here to diagnose the problem.
We'd need to see a more detailed trace and/or the ClientHello contents.
This could be https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0291,
which was fixed in 1.0.2b, but I can't tell.
Committed in fb029cebaeb6b0dbdb05a26a515e38a52a3c0fa1.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Fixed in 25d6b3401ca40c9a2cbe5080449c1c2a3703.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I believe this can't happen, but addressed in
394f7b6fcc38132b8ccff0a3253b9dd15640cfc0 anyway.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Fri, Aug 28, 2015 at 2:21 AM, Bill Cox <waywardg...@google.com> wrote:
> On Thu, Aug 27, 2015 at 5:00 PM, Emilia Käsper <emi...@openssl.org> wrote:
>
>> A client should (SHOULD) always repeat extensions on resumption though,
>> as it can't know whether the resumpt
Everything seems to be working as intended; closing this ticket.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Please see https://rt.openssl.org/Ticket/Display.html?id=3439
Your symptoms match, so it looks like unfortunately you were relying on an
OpenSSL bug to get the desired application behaviour.
___
openssl-dev mailing list
To unsubscribe:
Resolving - this was fixed in 1.0.1k.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Working as intended on the OpenSSL side. Marking resolved.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Resolving: seems that this was fixed in
dfba17b4f3b2f87b50f2251a608d1911bfd202bc
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, this is intentional. See also the issuer_hash_old and subject_hash_old
options in the x509 utility:
https://www.openssl.org/docs/manmaster/apps/x509.html
___
openssl-dev mailing list
To unsubscribe:
It's not really a bug. The behaviour upon resumption is extension-specific.
Most extensions are only needed for establishing the session; they're
ignored during resumption, and aren't stored in the session state. So it's
rather that the custom extensions API doesn't support stateful extensions.
A
Hi Ian,
Thanks for the report!
Your colleague John Foley suggested to treat this error as unrecoverable:
https://mta.openssl.org/pipermail/openssl-dev/2015-March/001030.html
The error is set while processing the ServerHello, at which point the PAC
has already been sent to the server in the
Fixed in 88f4c6f3d2f884715f8f5f8eb81f0a96cbec8cef, thanks for spotting!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Sun, Apr 26, 2015 at 10:37 PM, Brian Smith br...@briansmith.org wrote:
On Fri, Apr 24, 2015 at 5:54 AM, Emilia Käsper emi...@openssl.org wrote:
commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2).
commit 53dd4ddf71 fixes 5 and some of 4.
Still ploughing my way through the rest
On Fri, Apr 24, 2015 at 3:00 PM, Emilia Käsper emi...@openssl.org wrote:
Thanks for the report! Let me clarify a few points, and then I'll fix it.
On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith br...@briansmith.org
wrote:
Hi,
I have some questions regarding this implementation.
https
Thanks for the report! Let me clarify a few points, and then I'll fix it.
On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith br...@briansmith.org wrote:
Hi,
I have some questions regarding this implementation.
commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2).
commit 53dd4ddf71 fixes 5 and some of 4.
Still ploughing my way through the rest of error checking.
Cheers,
Emilia
On Fri, Apr 24, 2015 at 3:15 PM, Emilia Käsper emi...@openssl.org wrote:
On Fri, Apr 24, 2015 at 3:00 PM, Emilia
On Wed, Apr 1, 2015 at 10:53 PM, Brian Smith br...@briansmith.org wrote:
Emilia Käsper emi...@openssl.org wrote:
On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith br...@briansmith.org
wrote:
If OpenSSL's client code were changed to always use an empty session
ID when attempting resumption
the patch?
Erik
On 27 Mar 2015, at 12:33 PM, Emilia Käsper emi...@openssl.org wrote:
John, Erik,
https://github.com/openssl/openssl/pull/250
Can you verify whether this resolves the problem? (And also, does not
create any new problems.)
Note this is pending team review so
On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith br...@briansmith.org wrote:
Brian Smith br...@briansmith.org wrote:
Although the RFC4851 (an informational RFC documenting EAP-FAST) does
not require the server to send the session ticket extension during
resumption, it is based on
session. See section RFC 4851
Section 5.1. My understanding is this logic applies to both new and resumed
sessions. Hence, tls_session_secret_cb() is always in play for EAP-FAST.
On 03/26/2015 02:13 PM, Emilia Käsper wrote:
On Tue, Mar 24, 2015 at 2:01 PM, John Foley fol...@cisco.com wrote
actually want to do something like:
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
al = SSL_AD_INTERNAL_ERROR;
goto f_err;
On 03/23/2015 09:17 PM, Emilia Käsper wrote:
On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
wrote
On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
wrote:
We've found a way to recreate the scenario using s_client/s_server. We're
using the -no_ticket option on the server. Therefore, the ServerHello
doesn't contain the session ticket extension. It also doesn't send the
Error codes aren't part of the API. It's a bit of a grey area in some cases,
but for EVP_DecryptFinal_ex, you really should be checking the return value and
not relying on errors left on stack. In particular, reporting detailed
decryption errors was a historical mistake that has led to serious
Applied to all branches, thanks!
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
I've now pushed the missing commits to stable branches as well. For 0.9.8,
they are
af32df0a8e662914f78c93736466c746f83dfe84
and
9880f63038a5b9bb8bf5becc18360378cfe7806d
Emilia
On Fri, Oct 17, 2014 at 9:30 PM, Kyle Chapman kyle.chap...@pb.com wrote:
You can either patch e_os.h or when
Resolved - please see #3567 for details.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
FYI,
https://rt.openssl.org/Ticket/Display.html?id=3558 may also be of interest.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Appears to be a bad git merge on my side. I'm on it.
On Thu, Sep 25, 2014 at 1:23 PM, Ben Laurie b...@links.org wrote:
Workaround (I wasn't sure if the functions were intended to be used
somewhere, so not deleted yet):
diff --git a/crypto/constant_time_test.c b/crypto/constant_time_test.c
Fixed in fdc35a9d3e8cf4cfd9330d5df9883f42cf5648ad. Sorry about that,
Emilia
On Thu, Sep 25, 2014 at 1:28 PM, Emilia Käsper emi...@silkandcyanide.net
wrote:
Appears to be a bad git merge on my side. I'm on it.
On Thu, Sep 25, 2014 at 1:23 PM, Ben Laurie b...@links.org wrote:
Workaround (I
Thanks!
This is now in all branches in somewhat modified form (using the common
constant-time header), see commit
294d1e36c2495ff00e697c9ff622856d3114f14f
__
OpenSSL Project
And thanks once again!
This has now been backported from master commit
adb46dbc6dd7347750df2468c93e8c34bcb93a4b
to all other branches. Note that I rewrote the constant-time ops in the
follow-up commit
455b65dfab0de51c9f67b3c909311770f2b3f801
If you'd like to verify that I didn't mess up the
Thanks for reporting!
The leak would only be meaningful if the caller is doing mac-then-encrypt and
is attempting to proceed with the mac-check in constant-time following a call
to EVP_DecryptInit_ex. It also doesn't affect TLS mac-then-encrypt because TLS
uses a different padding scheme, and a
Thanks! This has now been applied to all branches.
(Original commit 2b0180c37fa6ffc48ee40caa831ca398b828e680)
__
OpenSSL Project http://www.openssl.org
Development Mailing List
1 - 100 of 104 matches
Mail list logo