Re: [openssl-dev] OPenssl 1.1.0 and FIPS

2017-09-16 Thread Salz, Rich via openssl-dev
> 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: https://mta.

[openssl-dev] Can I haz TLS 1.3 ?

2017-10-03 Thread Salz, Rich via openssl-dev
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 u

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

2017-10-03 Thread Salz, Rich via openssl-dev
Can the people involved in these Tests please speak up what's going on here? Particularly can you please name vendor names? Tbe TLSWG mailing list is probably a more effective place to have that discussion; I was just informing the OpenSSL community of the state of play ;) -- openssl

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

2017-10-23 Thread Salz, Rich via openssl-dev
➢ 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 … -- open

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

2017-10-23 Thread Salz, Rich via openssl-dev
>@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] FIPS module for 1.1.x ?

2017-11-21 Thread Salz, Rich via openssl-dev
FIPS remains a very important goal. Hopefully we’ll have more details to share in early December. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2017-12-05 Thread Salz, Rich via openssl-dev
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 pro

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

2017-12-06 Thread Salz, Rich via openssl-dev
You can re-use the keys, but then you get no forward secrecy, and sessions generated with one connection are vulnerable to another. Why are you using DH? Unless you have compelling reasons (interop with legacy), you really should use ECDHE. -- openssl-dev mailing list To unsubscribe: https://

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

2017-12-22 Thread Salz, Rich via openssl-dev
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] [openssl-users] Is X509_free(NULL) ok?

2017-12-22 Thread Salz, Rich via openssl-dev
> if (ptr!= NULL) free(ptr); That shouldn’t be necessary for OpenSSL. If you find places where it is, please open an issue. ➢ BTW, "can handle" should explicitly say what happens. Perhaps use the C library text, which says: If ptr is NULL, no operation is performed.

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

2017-12-22 Thread Salz, Rich via openssl-dev
➢ 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] Is X509_free(NULL) ok?

2017-12-22 Thread Salz, Rich via openssl-dev
➢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: htt

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

2018-01-01 Thread Salz, Rich via openssl-dev
Yes you can do so. It is documented in most of the manpages, and in 1.1.0 and later it should be in all of them. On 1/1/18, 11:19 AM, "Ray Satiro via openssl-dev" wrote: I'm trying to figure out whether it's supported to call X509_free(NULL) in 1.0.2 and beyond. It's not documented wh

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

2018-01-09 Thread Salz, Rich via openssl-dev
➢ 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 licens

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

2018-01-09 Thread Salz, Rich via openssl-dev
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] PKCS12 safecontents bag type deviation from spec

2018-01-16 Thread Salz, Rich via openssl-dev
OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE OF. Ouch! Will that cause interop problems if we change it? (I don’t remember the DER encoding rules) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

2018-01-19 Thread Salz, Rich via openssl-dev
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 pro

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

2018-01-19 Thread Salz, Rich via openssl-dev
➢ 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-p

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

2018-01-23 Thread Salz, Rich via openssl-dev
You should be able to just watch the openssl repo (the eyeball/watch notice in the upper-right side) On 1/23/18, 7:00 AM, "Hubert Kario" wrote: On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote: > There’s a new blog post at > https://www.

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

2018-01-23 Thread Salz, Rich via openssl-dev
➢ 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

2018-01-23 Thread Salz, Rich via openssl-dev
➢ 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! -- opens

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

2018-01-23 Thread Salz, Rich via openssl-dev
➢ github ones require me to go to the web UI which is slow I am confused by that. When someone posts an issue or comment, I get the text emailed to me. Not just openssl, but all projects I watch. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/ope

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

2018-01-23 Thread Salz, Rich via openssl-dev
➢ ah, true, I have those disabled because I use the same account for both my personal and my work projects so no single email address is correct for them At least we figured out the confusion! I have no good answer other than subject line filtering and forwarding, sorry. -- openssl-dev

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

2018-01-23 Thread Salz, Rich via openssl-dev
* OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html

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

2018-01-24 Thread Salz, Rich via openssl-dev
started is not going to give good results with or without locking. Peter From: "Salz, Rich via openssl-dev" mailto:openssl-dev@openssl.org>> To:"openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" mailto:openssl-dev@openssl.org>>

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

2018-01-24 Thread Salz, Rich via openssl-dev
* 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

2018-01-24 Thread Salz, Rich via openssl-dev
* Well, the most likely fix is to make the “safely” wording be more vague, which I doubt you’ll like. But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues. https://github.com/openssl/openssl/pull/5164 -- openssl-dev mailing list To unsubscribe: https://mta.op

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

2018-01-24 Thread Salz, Rich via openssl-dev
* 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 "unsaf

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

2018-02-05 Thread Salz, Rich via openssl-dev
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

<    1   2