Re: [openssl-dev] [openssl-master 0/1] AFALG: Support AES GCM

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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

* The current patch ( PR 5164 ) just changes "can be safely used" to "can generally be used safely". Without enough information for a user of the library to know whether a given usage is safe, this isn't useful documentation. When it comes to threading, "generally safe" is the same as

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

* 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:

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

* 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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

ctice.. If you are using those API's you are adding new crypto. methods. Doing that after threading has started is not going to give good results with or without locking. Peter From: "Salz, Rich via openssl-dev" <openssl-dev@openssl.org<mailto:openssl-dev@openssl.o

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

➢ 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. --

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

➢ 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:

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

➢ 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! --

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

➢ this feature sends notifications about _all_ conversations happening. For me, I get the actual comments that are posted. Don’t you? On the mailing list, you have to explicitly mark/junk conversation threads in your mail program. You would still have to do that here. I don’t understand

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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" <hka...@redhat.com> wrote: On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote: > There’s a new blog post

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

➢ 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-dev] Blog post; changing in email, crypto policy, etc

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

Re: [openssl-dev] PKCS12 safecontents bag type deviation from spec

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

➢ 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

Re: [openssl-dev] Is X509_free(NULL) ok?

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

Re: [openssl-dev] Is X509_free(NULL) ok?

➢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 unsubscribe:

Re: [openssl-dev] Is X509_free(NULL) ok?

➢ I think we fixed all such cases in 1.1.0, all *_free() functions should handle NULL. I don't think we backported to changes to 1.0.2. Yes, and we fixed the documentation. I backported all/most of them to 1.0.2 to make cherry-picking easier. I don’t know if I changed the docs.

Re: [openssl-dev] [openssl-users] Is X509_free(NULL) ok?

> 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 is

Re: [openssl-dev] Is X509_free(NULL) ok?

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

Re: [openssl-dev] A question DH parameter generation and usage

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:

Re: [openssl-dev] frequency and size of heartbeat requests

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

Re: [openssl-dev] FIPS module for 1.1.x ?

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

Re: [openssl-dev] New crypto algorithms in openSSL engine

>@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 requires

Re: [openssl-dev] New crypto algorithms in openSSL engine

➢ Really, about a ten years ago, when we first developed GOST engine, we have made patches, that allow to add ciphersuites dynamically. Unfortunately, that time core team haven't accepted these patches. Do you still have them available? We might make a different choice now … --

Re: [openssl-dev] Can I haz TLS 1.3 ?

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 play ;) --

[openssl-dev] Can I haz TLS 1.3 ?

Some people have asked why TLS 1.3 isn’t available yet. This might help; it’s a draft of a posting for my company’s blog. Can I Haz TLS 1.3 ? Everybody wants to be able to use TLS 1.3. Among the reasons are: It’s faster – being able to reconnect to a server you’ve previously

Re: [openssl-dev] OPenssl 1.1.0 and FIPS

> 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 unsubscribe:

Re: [openssl-dev] OPenssl 1.1.0 and FIPS

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

Re: [openssl-dev] 20170914 snapshots

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

Re: [openssl-dev] id-kp-OCSPSigning extended key usage

➢ 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

Re: [openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

Ø 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

Re: [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

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

Re: [openssl-dev] [openssl-users] how to compile out selected ciphers

What version of openssl are you building? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ > 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:

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ But now we just ignore it and assume every bit with get contains 1 ➢ bit of randomness and we're sundenly seriously overestimating the ➢ amount of randomness we're getting. This is a documented public API, ➢ you can't just go and ignore this parameter. Sure I can. Because the

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ I’d like to suggest that any approach other than “immediately mix the received randomness into the RNG state” is bad. If a user does RAND_add() now, as opposed to 100 source code lines before, there may be a reason for that. I think the only way to do that in the DRBG model is to treat it

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ IMHO this interface is a way for the user to improve the quality of the randomness it would get from the given RNG, *not* to replace (or diminish) its other sources. My proposal is to abolish this parameter, especially since now it is simply ignored (and IMHO – for a good reason). We

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

➢ An other problem with the current implemenation is that the ➢ randomness parameter that's now given to RAND_add() is just ➢ ignored, it assumes it's the same as the length. For what it’s worth, this was done deliberately, make RAND_add and RAND_seed equivalent. I am skeptical of

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? From your use-case: you want to add entropy into a specific DRBG. You want to push it, as opposed to the DRBG “pull when needed” model. That’s an additional API. Also from your

Re: [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

Getting the client connect right appears surprisingly messy when one needs to cope with all kinds of network error situations including domain name resolution issues and temporarily unreachable servers. Both indefinitely blocking and non-blocking behavior (i.e., connection

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

dev asap. If there are problems with it we can always revert it before it makes it into a release. Someone on the OMC called that “flip-flopping” and seemed to be against this kind of thing. If we are going to have an additional API, then we should at least see a draft of the header

[openssl-dev] CVE 2017-3735 OOB read

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

[openssl-dev] Reseeding at fork time

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.

Re: [openssl-dev] Work on a new RNG for OpenSSL

➢ Even opaque objects usually have some public interface. I think exposing RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an acceptable “live forever” API. That’s my point. API decisions live forever. Suppose we move around the DRBG’s so that they are

Re: [openssl-dev] Work on a new RNG for OpenSSL

>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

Re: [openssl-dev] Work on a new RNG for OpenSSL

>I personally see no harm if these RNG objects are made available to > applications that need/use them But decisions like this live forever. It is therefore VERY important to spend time thinking about what becomes part of the public API and what remains hidden so that we can change

Re: [openssl-dev] Work on a new RNG for OpenSSL

>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

Re: [openssl-dev] Work on a new RNG for OpenSSL

Okay: https://github.com/openssl/openssl/pull/4239 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

➢ But I’d like the development team to comment on (and ideally – accept) my request to add RAND_add() method to the RNG that is used in generation of private keys. Well, I’ve been thinking about this for a bit, since you first raised it. I am still not sure of the need. And as the blog post

Re: [openssl-dev] Work on a new RNG for OpenSSL

The problem with /dev/urandom will go away sooner or later. All major platforms either have a CPRNG syscall for years or introduced one recently. BSD has getentropy(2) for a while, Windows has CryptGenRandom() and Linux has getrandom(2) since Kernel 3.2 and glibc 2.15.

Re: [openssl-dev] Work on a new RNG for OpenSSL

It seems to me this all depends on the order of things you do to create a daemon. You could make sure the RNG is inited, chroot, and then fork for instance. And I suspect there are actually programs that do it in that order. Yes. I think the safest thing is for us to not

Re: [openssl-dev] Work on a new RNG for OpenSSL

\ > somewhere someone is. And then it’s not about just reseeding, but > what about when (if) we add other things, like whether or not the > secure arena gets zero’d in a child? It's difficult to think of what circumstances this might break existing code? What scenario did

Re: [openssl-dev] Work on a new RNG for OpenSSL

And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of It is documented in the RAND_add manpage. ➢ I’m not sure I agree here. What effort are you talking about? In order to select an order in

Re: [openssl-dev] Work on a new RNG for OpenSSL

>>> 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 one. Your application can always call

Re: [openssl-dev] Work on a new RNG for OpenSSL

> 1. What’s the default if “with-rand-seed” was not provided? All of the listed > supported types? None of them? Some of them…? As the first bullet says, it’s “os”. As for the second part of your question, it is deliberately not answered. If you care, you’ll have to read the source. (It’s

Re: [openssl-dev] Work on a new RNG for OpenSSL

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

[openssl-dev] FW: Code health tuesday is back!

A reminder: After a short summer vacation, our biweekly code health Tuesday is back! Our topic this time is … documentation. There have been many updates to the manpages in the past few weeks, typo fixes, additional clarifications, and so on.  We hope that folks will be emboldened to help

Re: [openssl-dev] Current master fails to build

> After that is fixed, test 80-test_new_ssl.t fails (wstat 256, 0x100). Do you have core file? The failure is not repeatable, at least on my system :( -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Code health tuesday is back!

After a short summer vacation, our biweekly code health Tuesday is back! Our topic this time is ... documentation. There have been many updates to the manpages in the past few weeks, typo fixes, additional clarifications, and so on. We hope that folks will be emboldened to help fill in the

Re: [openssl-dev] Master: test fails

;rs...@akamai.com>; openssl-dev@openssl.org Subject: Re: [openssl-dev] Master: test fails Sure looks like that... Regards, Uri Sent from my iPhone On Jul 22, 2017, at 14:41, Salz, Rich via openssl-dev <openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>> wrote: Wow that green is

Re: [openssl-dev] Master: test fails

Wow that green is hard to read ☺ So your config options change the tests for 70-test-tls13messages, but the plan isn’t updated, right? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] RNG seeding

There has been a great deal of useful discussion about how OpenSSL should seed its random number generator (CSPRNG). There's now a pull request that is mostly complete. Please take a look at https://github.com/openssl/openssl/pull/3956 and feel free to comment. In particular,

Re: [openssl-dev] openssl s_server "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a

You might find that the SSL library doesn’t have the code to do the old-style insecure renegotiation. If it does, then it probably makes sense to support this as a debugging option. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Compiler requirements

> beldmit> What is the minimal version of the compiler to build openssl? > beldmit> Is it still required C89 compatibility or C99 standard can be used? > beldmit> > beldmit> Unfortunately, I did not find these requirements in documentation. > > At the beginning of INSTALL, you will find a set of

Re: [openssl-dev] Dynamically adding a NID

> I tried using OBJ_create() with NULL or an empty string for the OID, but > currently it checks that the given OID is actually a valid one. Is there any > workaround to avoid this other than issuing my own OID? No. Just get an OID ARC, such as from the IETF Enterprise MIB [it's free] and

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Just to check my understanding, the claim is that adding more layers of > hashing and/or encryption will still be faster than a larger number of > syscalls? In terms of overall system performance? Yes. -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Work on a new RNG for OpenSSL

-- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz From: Benjamin Kaduk via openssl-dev [mailto:openssl-dev@openssl.org] Sent: Tuesday, June 27, 2017 9:22 PM To: openssl-dev@openssl.org; Paul Dale Subject: Re:

Re: [openssl-dev] Work on a new RNG for OpenSSL

That's interesting info Ted, thanks. But we don't currently know anything about which kernel or glibc version we're building for; maybe that has to change. (We barely, and rarely, look at the toolchain version.) And we need to be able to build a version which runs across a whole mess of

Re: [openssl-dev] Work on a new RNG for OpenSSL

> In case it wasn't clear, I think we should use the OS provided source as a > seed. By default that should be the only source of randomness. I generally agree. But some applications might save their state and restore it during boot time, for example. -- openssl-dev mailing list To

Re: [openssl-dev] Work on a new RNG for OpenSSL

> RAND_set_rand_method(RAND_drbg_method()); > > FIPS_drbg_set_reseed_interval() and > FIPS_drbg_set_callbacks() Take a look at https://github.com/openssl/openssl/pull/3789 Thanks! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Getrandom() is a syscall, and I have concerns about the syscall > > performance. I would rather feed getrandom (or /dev/random if that’s > > not available) into a FIPS DRBG generator. > > What is your concerns about syscall performance? What are your > performance requirements? I can tell

Re: [openssl-dev] Work on a new RNG for OpenSSL

For windows RAND_bytes should just call CryptGenRandom (or its equiv). For modern Linux, probably call getrandom(2). For OpenBSD call arc4random(). Getrandom() is a syscall, and I have concerns about the syscall performance. I would rather feed getrandom (or /dev/random if that’s not

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Well maybe I can ignore section 10.3? > > > > That's a nice joke Rich, but the Dual_EC_DRBG chapter has been dropped in > SP800-90Ar1, which supersedes SP800-90A: I know. I was trying to gently point out that even John makes mistakes :) > - Do you intend to continue supporting

Re: [openssl-dev] Work on a new RNG for OpenSSL

John, Thanks for pushing. It can be a thankless task, and I wanted to say thank you :) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Suppose the chip supports RDRAND but the runtime doesn't have > > getrandom or /dev/random? > > That's an easy one! > > Check the feature-test bit and then call RDRAND yourself. > Code to do this exists, e.g. Yeah, that's kinda what I meant we'd do. -- openssl-dev mailing list To

Re: [openssl-dev] Work on a new RNG for OpenSSL

> As for reliability, I don't know what "mediocre" means. Usually security- > critical code is correct or it's not. For a seed-source, either a lower > bound on > the amount of good "hard" randomness is available and reliable, or it's not. We run in many environments, and I don't think it's

Re: [openssl-dev] Work on a new RNG for OpenSSL

I was asked off-list why we're doing this. A reasonable question. :) There are many complains about the OpenSSL RNG. For started: https://github.com/openssl/openssl/issues/2168 https://github.com/openssl/openssl/issues/898 https://github.com/openssl/openssl/issues/2457

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Insofar as any hole that is not explicitly closed should be presumed open, > then yes, there are many holes. Any hole not known -- presumed open, or presumed closed? :) It's more about > What's your threat model? I know that sounds like a cliché, but it's actually > important. We're trying

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Do you think we need to use multiple sources of randomness? I think we > should only use the one source, the one provided by the kernel. Yes I think we will need to support it, such as systems that don't have kernel support. Always whitening doesn't hurt, so I would like to see the simpler

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Pseudorandomness of the output has been a design goal/requirement only > in SHA-3 family. Any prior hash function’s exhibition of this property is > coincidental. > > Therefore I suggest using SHA3 instead. Is pseudorandomness a requirement? Or is it the "50% chance of a bitflip"? --

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Is it worth reposting my thoughts with your suggested wording changes? > > OK. Off-list or on. This stuff is important. Reposting. My thoughts. Randomness should be whitened. Anything feed into an randomness pool, should be mixed in and run through SHA256. pool =

Re: [openssl-dev] Work on a new RNG for OpenSSL

> > Is it worth reposting my thoughts with your suggested wording changes? > > OK. Off-list or on. This stuff is important. I will repost. And please also see https://github.com/openssl/openssl/pull/3773 -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Suggestion: Get rid of every mention of "entropy" from openssl code, > documentation, design discussions, and everywhere else. I like this and will do it. Except for our support of the EGD. > Suggestion: In the common case where exact meaning is not important, > "entropy" can be replaced by

Re: [openssl-dev] discussion venue policy

Discussion should be here on the mailing list. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

> Will the new architecture still allow engine-defined RNG methods? It's a > critical requirement for our products. Yes -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

My thoughts. Entropy should be whitened. Anything feed into an entropy pool, should be mixed in and run through SHA256. pool = SHA256(pool || new-entropy) The current read and write file routines, and the current routine RAND_poll, etc., will add to that global pool. The idea

[openssl-dev] Work on a new RNG for OpenSSL

We are starting to work on a new cryptographically strong pseudo random number generator for OpenSSL, known as CSPRNG or PRNG or RNG. Please take a look at GitHub pull request https://github.com/openssl/openssl/pull/3758 which is the start of a series. In particular, please take a look at

Re: [openssl-dev] Dynamically adding a NID

You can get an OID arc of your own for free. And then you can use real OID’s which you just “throw away” See https://en.wikipedia.org/wiki/Private_Enterprise_Number -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Code Health Tuesday -- Fix the FAQ

It's been awhile since we did a code health Tuesday and we're overdue for one next week. Our online FAQ is really old; it's outdated and incorrect. We haven't fully figured out how much of the older versions and older platforms we should document. So, let's fix it. Move anything older than

Re: [openssl-dev] [RFC 0/4] Kernel TLS socket API

A couple of comments. First, until this shows up in the kernel adopted by major distributions, it is a bit premature to include in OpenSSL. Including netinet/tcp.h is seriously wrong to be part of openssl :) And finally, as I said before, the best way to get things in OpenSSL is to do pull

Re: [openssl-dev] Google OSS-Fuzz reward

Nicely done! > Cool. > > On 14 May 2017 at 10:49, Kurt Roeckx wrote: > > Google awarded us 1000 USD for the initial integration with OSS-Fuzz. > > See > > https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-a > > nd.html > > > > I have asked Google to donate it

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

Current master 1d0f116 fails on my machine. ../test/recipes/90-test_secmem.t .. 1..1 # Subtest: ./secmemtest 1..1 # INFO: @ test/secmemtest.c:65 # Possible infinite loop: allocate more than available # INFO: @ test/secmemtest.c:71 # Possible infinite loop: small arena

Re: [openssl-dev] shlibloadtest failure on non-Linux

> Sense of OPENSSL_USE_NODELETE has been reversed i.e. you want #ifdef > and not #ifndef Argh, you're right. > Also I think its still fair game to try a dlclose() just that the > dlclose() may return an error if OPENSSL_USE_NODELETE is not defined. I'll just leave it as-is. Thanks for looking

Re: [openssl-dev] shlibloadtest failure on non-Linux

> doesn't test for whether this is set. I think the shlibloadtest should only > test > the dlclose() return value on if OPENSSL_USE_NODELETE is set. Please see https://github.com/openssl/openssl/pull/3399 > 2) crypto/init.c at line 77 does "atexit(OPENSSL_cleanup)". If I try defining >

Re: [openssl-dev] Null pointer dereferences?

> The first was in crypto/async/async_wait.c on line 157. `prev` is assigned to > NULL on 144, and it doesn't look like it is assigned to anything in the while > loop. Line 177. > -OPENSSL_free(clienthello->pre_proc_exts); > +if(clienthello) { > +

[openssl-dev] Code heatlh delayed a week

We are still reviewing several PR's from the previous code health, which was about converting tests to use the new test framework. With this extended time period, we'll have ended up converting almost all the tests, which is great. We'll announce the next project toward the end of the week.

Re: [openssl-dev] 2 snapshots did not generate accordingly

> And What happened to openssl 1.0.1 ? We stopped supporting it back in December. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

  1   2   >