Please open a GitHub PR; posts to the mailing list won’t make it in.
BTW, the “iov” struct isn’t portable.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
do anything approaching a definitive
thread-safety analysis, let alone documentation. Even with the “small number
of API’s” that might be affected.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
* Well, the most likely fix is to make the “safely” wording be more vague,
which I doubt you’ll like. But I doubt anyone on the team has much interest in
fixing 1.0.2 locking issues.
https://github.com/openssl/openssl/pull/5164
--
openssl-dev mailing list
To unsubscribe: https
* OpenSSL should provide API to retrieve extension by OID.
Yes! Can you open a github issue for that?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Create the OID at your program startup and store the NID in a global variable.
From: Yun Jiang
Reply-To: openssl-dev
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in
crypto/objects/obj_dat.c
Thanks!
The
On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote:
>
> * OpenSSL APIs, which makes the following OpenSSL documentation
> statement invalid
> (https://www.openssl.org/docs/man1.0.2/crypto/threads.html
>
> <https://urldefense.proofpoi
* OpenSSL APIs, which makes the following OpenSSL documentation statement
invalid
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0
➢ ah, true, I have those disabled because I use the same account for both my
personal and my work projects so no single email address is correct for them
At least we figured out the confusion!
I have no good answer other than subject line filtering and forwarding, sorry.
--
openssl
➢ github ones require me to go to the web
UI which is slow
I am confused by that. When someone posts an issue or comment, I get the text
emailed to me. Not just openssl, but all projects I watch.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo
➢ For the lovers of NNTP: openssl-project has been added to news.gmane.org
as gmane.comp.encryption.openssl.project as readonly list.
I will always have a fondness for NNTP :) But that reminds me to nudge the
other mailing list distributors, and update the website. Thanks
what you see as different?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
You should be able to just watch the openssl repo (the eyeball/watch notice in
the upper-right side)
On 1/23/18, 7:00 AM, "Hubert Kario" wrote:
On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote:
> There’s a new blog post at
> https://www.
➢ It appears to me that you could use openssl-dev instead of openssl-project,
saving cycles on killing one and creating the other.
We discussed that, but it would be harder to “undo” if things don’t work out,
we wanted to make it very clear that this is a new way of operating, and
openssl
There’s a new blog post at
https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
It contains some important policy changes we decided at our meeting last month.
This includes:
- Closing the openssl-dev mailing list; use GitHub for issues
- New mailing list openssl-project for
ming
init/update/final signatures. That seems like precedent for adding such
APIs for the other types of EVP functionality, though getting a
non-wrapper implementation that actually allows ENGINE implementations
would be some amount of work.
-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE OF. Ouch!
Will that cause interop problems if we change it? (I don’t remember the DER
encoding rules)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
s, I was hoping to get a review on the suggested fix for the 1.0.2
> to see it is viable by the upstream first.
>
> Would it be possible to get a review on the openssl-dev@openssl.org
> alias? or filing an issue via github is the right course of action?
>
You already got a revie
I don’t think anyone is talking about OpenSSL depending on or requiring Apache;
that’s a non-starter.
It would be interesting to see how many changes you need to support your
platform.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 01/09/2018 08:32 AM, Randall S. Becker wrote:
> On January 9, 2018 8:41 AM, Rich Salz
>> ➢ We are currently modifying the source from Apache to OpenSSL open
>> source
>> licensing for the Speck/OpenSSL integration. Related repositories such
>> as the cipher i
On 01/09/2018 12:53 AM, Misaki Miyashita wrote:
>
>
> On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:
>> (switching the alias to openssl-dev@openssl.org)
>>
>> I would like to suggest the following fix so that a valid certificate
>> at .x can be recognized during th
➢ We are currently modifying the source from Apache to OpenSSL open source
licensing for the Speck/OpenSSL integration. Related repositories such
as the cipher itself will remain under the Apache license. We would love
input on the following items:
Don’t bother changing the
ly have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.
>
> Based on the above scena
Yes you can do so. It is documented in most of the manpages, and in 1.1.0 and
later it should be in all of them.
On 1/1/18, 11:19 AM, "Ray Satiro via openssl-dev"
wrote:
I'm trying to figure out whether it's supported to call X509_free(NULL)
in 1.0.2 and beyond.
➢So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
guaranteed for older 1.0.2.
yes.
➢ I also think it would be good to backport all to 1.0.2
Yes. I believe I did that, but I am not absolutely 100% positive.
--
openssl-dev mailing list
To unsubs
docs.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> if (ptr!= NULL) free(ptr);
That shouldn’t be necessary for OpenSSL. If you find places where it is,
please open an issue.
➢ BTW, "can handle" should explicitly say what happens. Perhaps use the C
library text, which says:
If ptr is NULL, no operation
Our intent is that all FREE functions can handle NULL. If you find things
missing or undocumented, please open an issue on GitHub. Thanks!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I'm trying to figure out whether it's supported to call X509_free(NULL)
in 1.0.2 and beyond. It's not documented what action occurs when the
pointer is null. Also generally speaking is it supported to call openssl
free functions with null pointers?
--
openssl-dev mailing list
y land, two if by sea, three if by the Internet."
On Dec 5, 2017, at 2:21 PM, Salz, Rich via openssl-dev
mailto:openssl-dev@openssl.org>> wrote:
The purpose of the HEARTBEAT message is for DTLS applications to determine the
maximum packet size and tune the application records accord
New page on the Wiki:
https://wiki.openssl.org/index.php/List_of_SSL_OP_Flags
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL Security Advisory [07 Dec 2017]
Read/write after SSL object in error state (CVE-2017-3737)
==
Severity: Moderate
OpenSSL 1.0.2 (starting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL version 1.0.2n released
===
OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/
The OpenSSL project team is pleased to announce the release of
version 1.0.2n of our open
You can re-use the keys, but then you get no forward secrecy, and sessions
generated with one connection are vulnerable to another.
Why are you using DH? Unless you have compelling reasons (interop with
legacy), you really should use ECDHE.
--
openssl-dev mailing list
To unsubscribe: https
thanks Hanno and Rich.
On Tue, 12/5/17, Hanno Böck wrote:
Subject: Re: [openssl-dev] frequency and size of heartbeat requests
To: openssl-dev@openssl.org
Cc: "Jitendra Lulla"
Date: Tuesday, December 5, 2017, 9:59 PM
On Tue, 5 Dec
The purpose of the HEARTBEAT message is for DTLS applications to determine the
maximum packet size and tune the application records accordingly. There is
never any reason to use this in TCP-based TLS; that was an OpenSSL bug that
enabled it there.
The usefulness of HEARTBEAT even in DTLS is
Hi,
With an "intentionally corrupted" tls1_heartbeat() in Openssl 1.0.2l, heart
beat requests with big payloads such as 16300 or slightly more can be
repeatedly sent to the server.
The server, religiously responds back with such big payloads after spending its
cpu on encry
wrote:
Subject: Re: [openssl-dev] Known apps supporting tls max frag size extn
To: "Jitendra Lulla" , openssl-dev@openssl.org
Date: Monday, December 4, 2017, 5:13 AM
> Also, I have lost the url of a website
which used to analyze any given server ( eg www.yahoo.com)
for its supp
extensions. You provide the
server url and it will display all the tls extns supported by that server. If
you know of any such url, could you please help me with that also.
Thanks
Jitendra
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
FIPS remains a very important goal. Hopefully we’ll have more details to share
in early December.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
; \
ln -sf /opt/csw/bin/gsed /usr/local/bin/sed && \
ln -sf /opt/csw/bin/gmake /usr/local/bin/make && \
ln -sf /opt/csw/bin/gpatch /usr/local/bin/patch
# Start a Bash shell
/opt/csw/bin/bash
# Set up environment
export
PATH=/opt/csw/bin:/usr/local/bin:/usr/sbin:/us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL Security Advisory [02 Nov 2017]
bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
==
Severity: Moderate
There is a carry propagating bug in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL version 1.1.0g released
===
OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/
The OpenSSL project team is pleased to announce the release of
version 1.1.0g of our open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL version 1.0.2m released
===
OpenSSL - The Open Source toolkit for SSL/TLS
https://www.openssl.org/
The OpenSSL project team is pleased to announce the release of
version 1.0.2m of our open
>@Victor; Are you saying so that the patches that enabled the GOST
ciphersuite be added are not included in openSSL? If so, would that mean
it's not possible for me to fork off openSSL and follow the GOST template?
Not quite. He’s saying that adding new crypto to TLS
e now …
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
allow an opt-out (probably not).
-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Can the people involved in these Tests please speak up what's going on
here? Particularly can you please name vendor names?
Tbe TLSWG mailing list is probably a more effective place to have that
discussion; I was just informing the OpenSSL community of the state of
1.3 has been in WGLC for weeks. So why can’t we use it
yet?
First, the different drafts don’t interoperate. Each represents a different
milestone on the way to the full specification, and a flag in the header
identifies which draft is being used. OpenSSL, used by most of the servers on
the
M Benjamin Kaduk via openssl-dev <
openssl-dev@openssl.org> wrote:
> Hi all,
>
> Doing some testing with a snapshot of master (s_client with -tls1_2 and
> optionally a cipherspec that prefers ECDHE ciphers), we're running into
> a sizeable number of servers that are sending ex
of groups
supported by the server).
In OpenSSL 1.1.0 we seem to have treated the elliptic_curves extension
in a ServerHello as an extension unknown to the library code and passed
it off to the custom extension handler. With the extension processing
rework in master done to support TLS 1.3, which
"-fomit-frame-pointer" is no longer allowed for armv7 targets, so I removed
it from the iphoneos-cross configure target. I noticed this
on openssl-1.0.2l.
--- Configure.orig 2017-05-25 05:54:38.0 -0700
+++ Configure 2017-09-29 12:09:45.0 -0700
@@ -652,7 +652,7
6-autoca;h=05e221b313225f23fe9986003eebcd3ba2be5ce8;hb=HEAD
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 09/18/2017 09:32 AM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> RSA-OAEP supports different hash functions and MGF. SHA-1 is the default.
>
>
>
> OpenSSL implementation of OAEP wrongly refuses to set the hash
> algorithm, preventing one from using SHA-2 family:
>
&g
gets sent out, but I only saw a TLS 1.2 version being
> sent.
> Is this a bug?
The legacy_version field in a TLS 1.3 ClientHello will be 0x0303,
matching the historical value for TLS 1.2. The actual list of versions
are conveyed in a "supported_versions" extension, which is what you need
to be looking at.
-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Roumen Petrov wrote:
Howard Chu via openssl-dev wrote:
In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on
libpthread but this is not reflected in the pkgconfig file. As a result,
tools like CMake fail to detect libcrypto properly when linking against the
static library
In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on
libpthread but this is not reflected in the pkgconfig file. As a result, tools
like CMake fail to detect libcrypto properly when linking against the static
library. libpthread should be added to the Libs.private line of the
> FIPS is not supported for 1.1.0
>
>jUST A SMALL FIX WILL DO.
No. All of the FIPS supporting code has been pulled out of 1.1.0 Even if you
get it to compile, it will fail at link or runtime because of missing functions.
--
openssl-dev mailing list
To unsubscri
Tryong to compile Fips into OPEnssl-1.1.0 and I run into
FIPS is not supported for 1.1.0
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We did some system upgrades and they were down during the update time.
As I’ve said before, please wait for at least a second day before writing about
the snapshots.
On 9/14/17, 8:09 AM, "The Doctor" wrote:
They are missing in action!
--
openssl-dev mailing list
To unsubscr
ion SHALL be designated by the inclusion of
id-kp-OCSPSigning in an extended key usage certificate extension
included in the OCSP response signer's certificate.
The use of "SHALL" rather than "MUST" indicates that this recommendation can be
ignored.
How does openssl handle
➢ Thanks for the clarification. Per the spec, then, a certificate designated to
sign OCSP responses is required to have the ocsp-sign bit in the key usage
extensions set.
➢ How does openssl handle cases where this requirement is violated?
Look at check_delegated() in ocsp/ocsp_vfy.c It returns
o if by sea, three if by the Internet."
On Sep 11, 2017, at 10:43 AM, Daniel Kahn Gillmor
mailto:d...@fifthhorseman.net>> wrote:
On Mon 2017-09-11 14:16:11 +, Short, Todd via openssl-dev wrote:
Yes, it’s annoying, but it’s historic. I looked into changing this at one point.
I think Di
or.
Thank you!
--
SY, Dmitry Belyavsky
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 09/06/2017 05:24 PM, Matt Caswell wrote:
> Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused
> me to take a close look at QUIC. This seems to have been getting a *lot*
> of attention just recently. See the IDs below for details:
Yes, it's generated a lot of
Ø Config & build script (feel free to suggest improvements, BTW):
Perhaps don’t cut/paste green-on-black color? Plaintext is probably sufficient.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
FWIW, there’s a ‘libtls’ library from the libre folks that might be worth
looking at.
If you come up with useful snippets we can start by posting them to the wiki,
for example
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
What version of openssl are you building?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
➢ > Sure I can. Because the DRBG seeds from the system anyway
➢ You can't assume that will work for all users.
And for places where the systesm doen’t have enough randomness, there is
nothing we can do.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org
n. Because the DRBG seeds from the system anyway
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
operation I’m now concerned with, and that I want to
influence/improve. This would probably differ between per-SSL DRBG and
per-thread DRBG, etc. I haven’t even thought about this part of the API (and
I’m sure others on the team have more experience and understanding of the
OpenSSL code to do it
cannot do this in a minor release; we have to wait until 1.2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
lly since
> now it is simply ignored (and IMHO – for a good reason).
That's a fine proposal ... it just can't be implemented until a major
release boundary, when our ABI stability policy permits such breaking
changes.
-Ben
--
openssl-dev mailing list
To unsubscribe: https://mta.openss
eptical of the ability to get that estimate correct.
Someone on GH there is a conversation thread about turning that into a
percentage, which seems like the best thing to do for any new API.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
: you want to specify which DRBG instance gets
that entropy. If we move to a pair per thread, as opposed to one per SSL and
two in the global space, how do we make sure that API still works and does the
right thing.
Does that makes sense, and does it answer your question?
--
openssl-dev
On 08/29/2017 05:17 AM, Matt Caswell wrote:
> On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
>> Currently, the OpenSSL core members seem to be reluctant to make the
>> API public, at least at this early stage. I understand Rich Salz's
>> viewpoint that this requ
*SSL_connection(int socket, const char *servername, …whatever…)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
➢ Yes. And per fairly recent recommendations to avoid cluttering the
➢ name space, that would be OSSL_DRGB_CTX and OSSL_DRGB_METHOD, btw.
DRBG is used for RAND stuff, so I don’t see a good reason to not using
RAND_DRBG as the prefix
--
openssl-dev mailing list
To unsubscribe: https
file first.
Keep in mind that the current DRBG organization might change, and we don’t want
to lose that freedom.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
From https://www.openssl.org/news/secadv/20170828.txt
OpenSSL Security Advisory [28 Aug 2017]
Malformed X.509 IPAdressFamily could cause OOB read (CVE-2017-3735)
===
Severity: Low
If an X
For those interested, there is a lot of discussion going on over at
https://github.com/openssl/openssl/pull/4239
I consider it bad that the conversation is happening there, not here, but so it
goes. If you don’t have a GitHub account and wish to post, forward to me and I
will post it for you
-thread, or per-SSL_CTX or per-SSL object? Will
that API still work? Or will we need a A “RAND_ex_ex” function? We don’t have
even consensus on when and how to reseed.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>This is why I want to add things like that by default in the
>additional data.
On reseed or generate?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
change things later when we have a better understanding.
This concept is new to OpenSSL :) But we just put out a 1.1.0 release that
made things opaque, so it’s more fresh in the minds of at least some of the dev
team.
Personally, since DRBG is new in 1.1.1 I would be quite happy if we didn’t
>An idea that I had was to default to reseed on fork if we know we
>have a working syscall.
Or /dev device too?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Okay: https://github.com/openssl/openssl/pull/4239
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We should think carefully about what API’s we are exposing, and might want to
wait for 1.1.2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
ST SP 90A is right, or you just bypass it completely.
We’re in the first camp. But it’s open source, do what fits your needs.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Is this new RNG object available to user programs, or do they need
to reinvent the wheel even though they definitely link against the
OpenSSL library?
You don’t have to re-invent the wheel, but you might have to modify the source
☺ Did you read the blog posting? What wasn’t
says, we’re not convinced
that the current DRBG arrangement is something that will never change. But I
think a new API, RAND_add_ex that took a flag that had values like
RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, RAND_LOCAL_PRIVATE
indicating which to seed. Thoughts?
--
openssl
.
Agreed.
And when we can make –with-rand-seed=syscall the default, then it will be a
happier place ☺
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
change the default. Programs that
know they are going to fork can do the right/safe thing. It would be nicer if
we could automatically always do the right thing, but I don’t think it’s
possible.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
t scenario did you have in mind?
As excerpted above in my post.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
not guarded by
RUN_ONCE(). This should be fixed, too.
Yeah, I’ll fix that; thanks.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Compilation of AFALG engine"
I will fix this problem now by having proper setup. Will update if I face any
more issues.
Thanks
Jitendra
----
On Wed, 8/16/17, Jitendra Lulla wrote:
Subject: Re: afalg with OpenSSL 1.1.0f 25 May 2017
To: "
N(K_MAJ, K_MIN1, K_MIN2));
printf("LINUX_VERSION_CODE %d\n", LINUX_VERSION_CODE);
printf("condition:%d\n",
(LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1,
K_MIN2)));
}
On Mon, 8/14/17, Matt Casw
justification for this. It seems to me that if
you accept the DRBG document, which we do, then the way we do the seeding is
fine. If you don’t accept the document, then modify the source.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>> 3. What should I do if I want a given source to be used in addition to the
>>> other sources, regardless of whether openssl thinks it got “enough bits” of
>>> randomness or not?
>> Modify the source :)
>Very bad answer.
And also a wrong on
> other sources, regardless of whether openssl thinks it got “enough bits” of
> randomness or not?
Modify the source :)
For a few reasons, we’re deliberately not documenting all the details.
Interested parties will have to read the source.
--
openssl-dev mailing list
To unsubscribe: ht
Thanks everyone for the discussion (mainly in June) about this. There’s a blog
post describing what we’ve done for the 1.1.1 release:
https://www.openssl.org/blog/blog/2017/08/12/random/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hi,
I am trying to use afalg on Linux 4.9.37 with OpenSSL 1.1.0f.
I am facing 2 issues:
ONE: when I issue the speed command, I see the following:
[root@localhost apps]# ./openssl speed -evp aes-128-cbc -engine afalg
invalid engine "afalg"
139853452924736:error:2506406A:D
1 - 100 of 554 matches
Mail list logo
