Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

The tool looks good, but either you didn't find the right link, or it's got bugs. Of the four symbols you found, ASN1_STRING_clear_free(), SRP_user_pwd_free(), and SRP_VBASE_get1_by_user() all exist; only ENGINE_load_rsax() was removed. -- Senior Architect, Akamai Technologies Member, Ope

[openssl-dev] Heads up -- RT tickets moving to GH issues

Just to let you know, we found a tool to migrate RT to GitHub issues and will be doing that shortly. This will just about double the number of open issues we have and, unfortunately, push the existing (active ones) down a few pages. -- openssl-dev mailing list To unsubscribe: https://mta.opens

Re: [openssl-dev] [openssl.org #4681] Resolved: X.509 load method

> Resolved? > Hmm, how to implement X.509 lookup method with 1.1+ API? It wasn't really resolved, it was moved to GH issue 2531. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Openssl 1.0.2 stable SNAP 20170309 issue

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

[openssl-dev] Code Health Tuesday -- testing!

Participate in the second Code Health Tuesday (Mar 14th) Hi OpenSSL developers! In our continuing quest to improve code quality and pay our technical debt, our second Code Health Tuesday is focused on testing. We declare this Tuesday (Mar 14th) Code Health Tuesday. We'll be setting some

[openssl-dev] Tuesday's code health day

Our most recent code health Tuesday was a success. Nearly a dozen people worked to achieved the following: - Our external contributors wrote completely new unit test for previously untested API's (stack, LHASH, and RSA_padding_add_PKCS1_PSS_mgf1) , and added a large external test suite (Python

Re: [openssl-dev] License change agreement

> The major problem with the existing license is that it conflicts with the > GPLv2. Well, it's one of the problems. The others includes that it is non-standard, and has an advertising clause. > The new license also conflicts with the GPLv2. This was immediately brought > up as a serious prob

Re: [openssl-dev] License change agreement

> As was noted back when this was brought up in 2015, there are other, better, > licenses than the APLv2 which are also GPLv2 compatible. The MPLv2 being > an example of such a license. There is also BSD, MIT/X11, etc. The > GPLv2 incompatibility of OpenSSL is a major problem. Better in one dim

Re: [openssl-dev] License change agreement

The required source code disclosures of the MPL are problematic. The fact that the MPL allows distribution under a non-patent-protecting license is problematic. Ok? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

> Thanks Rich, that's a more useful starting point. Has dual licensing been > considered? Both in 2015 and now, the lack of GPLv2 compatibility has > shown to be a serious drawback to the APLv2. Dual licensing means that it is also available under a no-patent-protection license which is an issu

Re: [openssl-dev] License change agreement

> > Dual licensing means that it is also available under a > > no-patent-protection license which is an issue for us. > > APLv2 and MPLv2 both have patent protections. How would a dual license of > APL+MPL result in a no-patent-protection license? MPL allows GPL which has no patent protection. -

Re: [openssl-dev] License change agreement

> It doesn't mean the code is no longer covered by the MPL. See > , That is very complicated as can be seen by the multiple cases, all of which we would expect to apply to OpenSSL at one point or another. Our legal advice discourage

Re: [openssl-dev] License change agreement

> It's not clear to me that that's correct. From > (See update), it appears you need an > explicit 95% permission rate to legally relicense and zero objections. So > far one objection has already surfaced. And code from people who object will most likely have

Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible

> Please, in the final OpenSSL license text add the paragraph linked in the > above LLVM mailing list as an exception to the Apache license. > > We should make sure using OpenSSL in GPLv2-only projects its possible > without any trouble or concern for developers. The problem is that if it is di

Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible

> > The problem is that if it is distributed under the GPLv2 there is no > > patent protection, and that is important to us. > > I've already told you once that this is a factually incorrect statement > because > (L)GPLv2 contains an implicit patent licence: By patent protection, I mean "you los

Re: [openssl-dev] Renegotiation ticket 3712

> The issue is fairly time sensitive and leads to non-deterministic outcome. > > Hence I was expecting the issue to be addressed with openssl version 1.1.0 > due to major overhaul of state machine and internals. Perhaps a more accurate way to say it is "I was hoping ..." :) If this is important

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

Look at https://www.openssl.org/community/ and https://www.openssl.org/community/getting-started.html as useful starting points. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Problem displaying rsa private key.

modulus:     00:cd:a7:cc:46:17:97:e6:89:e7:bb:36:e2:4d:f0: Without the leading zero, the 0xCD would be interpreted as a negative number according to ASN1/DER rules. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch

> Did the no-fips option get removed by-design? Are the no-* corollaries going > to be dropped going forwards? Yes. All FIPS support was removed. It could be brought back, and made a no-op, if that's a real issue. There are no plans to remove any other no-* at this time. -- openssl-dev mailin

Re: [openssl-dev] Question about no-* options (no-fips in particular) on 1.1 branch

> Yes. All FIPS support was removed. It could be brought back, and made a > no-op, if that's a real issue. By it, I meant the "no-fips" option -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow

>??? memset(&str->data[str->length], 0, len - str->length); The intent is to blank out everything from what was currently written. This "covers up" possible pointer over-runs. We could do just from the old max. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/lis

Re: [openssl-dev] ETA: TLS 1.3 release

> Out of curiosity, what's the ETA for TLS 1.3? > [1] mentions April 5 as the release date (which was two weeks ago). > > [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html That's an akamai blog, not an openssl statement :) And that post is misleading, it should have said "available" not "re

Re: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow

> Requesting you also to check and provide your suggestions on it. > https://github.com/openssl/openssl/pull/3255 As Matt and Kurt have said, this seems to be 'covering up' real bugs in the source. It doesn't seem like a good idea. -- openssl-dev mailing list To unsubscribe: https://mta.openss

Re: [openssl-dev] Wiki adjustments

> In https://wiki.openssl.org/index.php/Android the ./config command sets -- > openssldir but not --prefix which causes issues in 1.1.0 apparently. Fixed, thank you ! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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. Th

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_free(clienthello->pre_pro

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

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] 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] 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 to European Digit

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] 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 1

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] 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 some

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

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

> 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] 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: https://mta.openssl.org/mailman/listinfo/op

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 = SHA25

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"? -- openssl-

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 lo

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

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

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

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 unsubscr

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

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

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 availabl

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 y

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

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

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

> I think we can get away with using OS-provided randomness directly in many > common cases.  /dev/urandom suffices once we know that the kernel RNG has > been properly seeded.  On FreeBSD, /dev/urandom blocks until the kernel RNG > is seeded; on other systems maybe we have to make one read from

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 kernel

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: [openssl-dev] Work on a new R

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: https://mta.openssl.org/mailman/listinfo/opens

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 thro

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 r

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

[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, https://githu

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

Re: [openssl-dev] Master: test fails

; 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 mailto:openssl-dev@openssl.org>> wrote: Wow that green is hard to read ☺ So your config options change the tes

[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 gap

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] 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 fill

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

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

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

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 whic

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

I understand the concern. The issue I am wrestling with is strict compatibility with the existing code. Does anyone really *want* the RNG’s to not reseed on fork? It’s hard to imagine, but maybe somewhere someone is. And then it’s not about just reseeding, but what about when (if) we add oth

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

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 chan

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

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 s

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 cl

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

➢ P.S. I wonder if it's feasible to have a configuration parameter that would allow me to tell the TLS code to invoke RAND_add_ex() before generating session keys? At this point, you might as well just change the code to use getrandom() and pass it through. Either you accept that NIST SP

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

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

>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

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

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

➢ 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 per-threa

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

[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 X.50

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 f

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

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

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 atte

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 use-case:

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 th

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 cann

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

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

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: https://mta.openssl.org/mailman/li

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] 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] 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] 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] 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 list To unsubscribe: https:/

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

  1   2   >