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

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/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,

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

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

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

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

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

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

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

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

[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

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

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

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

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

>??? memset(>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:

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

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

[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

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

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

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

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

;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

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

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

> 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

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

➢ 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

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

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

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

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

> 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

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

> 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

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

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

[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] 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) { > +

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

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

> 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

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

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

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

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

>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

[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

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

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

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

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

  1   2   >