[openssl-dev] Default installation of OpenSSL

Hello, I get problems building and installing OpenSSL 1.1.0g from source. After running ./config; make; make test; sudo make install I call /usr/local/bin/openssl I get an error /usr/local/bin/openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No

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] [openssl-master 0/1] AFALG: Support AES GCM

On Mon, Feb 05, 2018 at 12:08:38PM +0530, Atul Gupta wrote: > The objective of this patch is to add AEAD cipher aes-gcm > to afalg. Portion of code is borrowed from e_aes.c. The AEAD > auth size is set to program the TAG length. AAD (additional > authenc data) is sent in iov along with data[in].

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

The objective of this patch is to add AEAD cipher aes-gcm to afalg. Portion of code is borrowed from e_aes.c. The AEAD auth size is set to program the TAG length. AAD (additional authenc data) is sent in iov along with data[in]. The code is tested with s_server/s_client and apache. Atul Gupta

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

Extends afalg functionality to another AES cipher. GCM, will enable TLS to use hardware crypto accelerator through AF_ALG socket. Support keysize 128,192 ans 256. Signed-off-by: Atul Gupta --- engines/e_afalg.c | 568 --

Re: [openssl-dev] GCM for AFALG engine

On 02/02/18 11:18, Atul Gupta wrote: > I want to add GCM support to afalg engine and have the patch tested with > apache and s_server/s_client. Can I submit the patch for review? Any > suggestion? A patch would be most welcome. All patches should be submitted through github. Please make sure

[openssl-dev] GCM for AFALG engine

Hi, I want to add GCM support to afalg engine and have the patch tested with apache and s_server/s_client. Can I submit the patch for review? Any suggestion? The existing afalg supports only aes-128-cbc, the work adds support for: 1. 192 and 256 key size for AES-CBC 2. AES-GCM for 128,

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

> On Jan 25, 2018, at 5:11 AM, Richard Levitte wrote: > > This is confusing, and not what was intended. In other words, > openssl-project is *not* a new openssl-dev! If it was, I don't see > why we would even bother making a new list... It is moderated, and won't have

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

In message on Wed, 24 Jan 2018 13:08:54 -0500, Viktor Dukhovni said: openssl-users> > If we agree that mailing lists are preferrable to openssl-users> > GitHub threads, then we should not close down openssl-users> >

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

On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev wrote: > On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote: >> 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

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

Viktor Dukhovni wrote: >> On Jan 24, 2018, at 9:27 AM, Michael Richardson wrote: >> >>> email clients are designed to handle hundreds to thousands of messages >>> a day, Github UI isn't > Indeed email is best for informal

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

> On Jan 24, 2018, at 1:25 PM, Dr. Matthias St. Pierre > wrote: > > Ok, I didn't know that. If anyone seriously participating on GitHub can > join the moderated openssl-project list then this sounds like a good > replacement for openssl-dev, because that list

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

On 24.01.2018 19:08, Viktor Dukhovni wrote: > > Well, but we now have "openssl-project" for discussions of the > ongoing development of OpenSSL. It is mostly for team members, > but though it is moderated, IIRC others can join and post. Ok, I didn't know that. If anyone seriously participating

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

> On Jan 24, 2018, at 12:55 PM, Dr. Matthias St. Pierre > wrote: > > As for the two mailing lists openssl-users and openssl-dev: It was always > my understanding that the former was for usability questions starting > from newbie questions up to very sophisticated

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

Viktor Dukhovni wrote: |> On Jan 24, 2018, at 9:27 AM, Michael Richardson wrote: |>> email clients are designed to handle hundreds to thousands of messages |>> a day, Github UI isn't | |Indeed email is best for informal ad-hoc back and forth

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

On 24.01.2018 18:32, Viktor Dukhovni wrote: > >> On Jan 24, 2018, at 9:27 AM, Michael Richardson wrote: >> >>> email clients are designed to handle hundreds to thousands of messages >>> a day, Github UI isn't > Indeed email is best for informal ad-hoc back and forth threaded

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

> On Jan 24, 2018, at 9:27 AM, Michael Richardson wrote: > >> email clients are designed to handle hundreds to thousands of messages >> a day, Github UI isn't Indeed email is best for informal ad-hoc back and forth threaded discussion, while Github et. al. are for issue

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

Thanks! But we are providing SDK to our customers to retrieve extension from the certificates downloaded from Internet. We have no idea what OID will be used by the SDK users. Only SDK users will know what OID will be expected in a certificate. OpenSSL should provide API to retrieve extension

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

Create the OID at your program startup and store the NID in a global variable. From: Yun Jiang Reply-To: openssl-dev Date: Wednesday, January 24, 2018 at 7:38 AM To: openssl-dev Subject: Re: [openssl-dev] About

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

Hubert Kario wrote: > that marking a conversation as ignored and going to next one is two key > combinations and less than a second, github ones require me to go to > the web UI which is slow, and if I have to view the issue because > subject is ambiguous it

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

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

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

Thanks! The problem is that I need to get a customized certificate extension based on an OID. Until now, I cannot find a solution without dynamically calling OBJ_create(OID, NULL. NULL). Yun From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Peter Waltenberg Sent: 24

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

Thanks! Is this issue fixed in 1.1.0? Yun From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, Rich via openssl-dev Sent: 24 January 2018 01:19 To: openssl-dev@openssl.org Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

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

The APIs defined in the file crypto/objects/obj_dat.c share some static global variables defined in the file without locking, which makes the APIs in this file not multi-thread safe even if the locking callbacks are set. In addition, the APIs in this file are also used by the other OpenSSL

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

* Hubert Kario: > when I mark project as followed I'm getting messages from all issues > and all PRs - likely dozens if not hundred messages a day But isn't that the point? My main concern with Github is that I have no record of my own actions. (Their single-account policy is also a problem

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

In message <8c351e82-600b-487e-aef3-a3f42cd23...@akamai.com> on Tue, 23 Jan 2018 14:38:14 +, "Salz, Rich via openssl-dev" said: openssl-dev> openssl-dev> ➢ For the lovers of NNTP: openssl-project has been added to news.gmane.org openssl-dev> as

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

On Tuesday, 23 January 2018 16:13:30 CET Salz, Rich wrote: > ➢ 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. ah, true, I have those

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

On 23.01.2018 15:54, Hubert Kario wrote: > On Tuesday, 23 January 2018 15:36:26 CET Salz, Rich wrote: >> ➢ this feature sends notifications about _all_ conversations happening. >> >> For me, I get the actual comments that are posted. Don’t you? > when I comment in an issue/PR or mark it as

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

On Tuesday, 23 January 2018 15:36:26 CET Salz, Rich wrote: > ➢ this feature sends notifications about _all_ conversations happening. > > For me, I get the actual comments that are posted. Don’t you? when I comment in an issue/PR or mark it as followed I'm getting only messages from that

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

On Tuesday, 23 January 2018 15:22:13 CET Salz, Rich wrote: > You should be able to just watch the openssl repo (the eyeball/watch notice > in the upper-right side) that's what I was talking about this feature sends notifications about _all_ conversations happening. > On 1/23/18, 7:00 AM,

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

Salz, Rich via open ssl-dev in gmane.comp.encryption.openssl.devel (Fri, 19 Jan 2018 17:34:57 +): >- New mailing list openssl-project for project discussions For the lovers of NNTP: openssl-project has been added to news.gmane.org as gmane.comp.encryption.openssl.project as readonly

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

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

Hello, On Tue, Jan 23, 2018 at 3:00 PM, 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.openssl.org/blog/blog/2018/01/18/f2f-london/ > > > We decided to increase our use of

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

On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote: > There’s a new blog post at > https://www.openssl.org/blog/blog/2018/01/18/f2f-london/ > We decided to increase our use of GitHub. In addition to asking that all bug > reports and enhancement requests be reported as

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

On 1/19/18, 12:52, "Salz, Rich" wrote: >> 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 >

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

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. -- Regards, Uri Blumenthal On 1/19/18, 12:35, "openssl-dev on behalf of Salz, Rich via openssl-dev"

[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] [openssl/openssl] Dtls listen refactor (#5024)

On 19/01/18 16:32, Michael Richardson wrote: > Matt Caswell wrote: > > Please raise a separate PR for this work. It *must* be portable though > > and work across all our platforms (e.g. including VisualC etc). My > > suggestion is that your

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

Matt Caswell wrote: > Please raise a separate PR for this work. It *must* be portable though > and work across all our platforms (e.g. including VisualC etc). My > suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR > ctrls should return an

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 17/01/18 16:34, Michael Richardson wrote: > > > It seems like a fairly simple solution could solve this. Currently we > > have BIO_dgram_get_peer() which returns the peer's address for the last > > message read from a BIO. You could imagine a new call being introduced > > to

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

On Thu, Jan 18, 2018 at 05:34:05PM +0100, Patrick Steuer wrote: > > Though aead is in some sense more than a cipher mode of operation. Providing > a dedicated api would have some advantages but i see that maybe i reopen a > discussion: > > "We are also evaluating the following new features. -New

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

Matt Caswell wrote: >> Matt Caswell wrote: >> >> Matt Caswell wrote: >> a) when the existing FD is >> >> connect(2) any future traffic to the bound >> port will get rejected >> >> with no port. So the application really has

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

On 01/18/2018 02:37 AM, Peter Waltenberg wrote: Or just add another EVP_CIPHER_CTX_ctrl() option (EVP_CTRL_CIPHER_ONE_SHOT or similar.) and handle it the way CCM does now and finish the operation on the first data update. That doesn't require a new API and would probably simplify some existing

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

Or just add another EVP_CIPHER_CTX_ctrl() option (EVP_CTRL_CIPHER_ONE_SHOT or similar.) and handle it the way CCM does now and finish the operation on the first data update. That doesn't require a new API and would probably simplify some existing code. Peter From: Patrick Steuer

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

On 01/17/2018 12:04 PM, Patrick Steuer wrote: > libcrypto's interface for ciphers and digests implements a flexible > init-update(s)-final calling sequence that supports streaming of > arbitrary sized message chunks. > > Said flexibility comes at a price in the "non-streaming" case: The >

[openssl-dev] evp cipher/digest - add alternative to init-update-final interface

libcrypto's interface for ciphers and digests implements a flexible init-update(s)-final calling sequence that supports streaming of arbitrary sized message chunks. Said flexibility comes at a price in the "non-streaming" case: The operation must be "artificially" split between update/final.

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

Matt Caswell wrote: >> Matt Caswell wrote: >> a) when the existing FD is >> connect(2) any future traffic to the bound >> port will get rejected >> with no port. So the application really has to >> open a new socket >> first. The application

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

On Tue, 2018-01-16 at 19:31 +, Sands, Daniel wrote: > On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote: > > 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

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

I think the change is justified. — Regards, Uri > On Jan 16, 2018, at 14:31, Sands, Daniel wrote: > > On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote: >> OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE >> OF. Ouch! Will that cause

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 16/01/18 19:44, Michael Richardson wrote: > > Matt Caswell wrote: > >> a) when the existing FD is connect(2) any future traffic to the bound > >> port will get rejected with no port. So the application really has to > >> open a new socket first. The

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

Matt Caswell wrote: >> a) when the existing FD is connect(2) any future traffic to the bound >> port will get rejected with no port. So the application really has to >> open a new socket first. The application can do this two ways: it can >> open a new socket

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

On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote: > 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) > > > Well, a SEQUENCE uses tag 16 while a SET

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 16/01/18 15:32, Michael Richardson wrote: > > a) when the existing FD is connect(2) any future traffic to the bound port >will get rejected with no port. So the application really has to open a >new socket first. >The application can do this two ways: it can open a new socket on

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

please see https://github.com/openssl/openssl/pull/5024 mattcaswell asks on github: mattcaswell> I am unclear about the underlying premise of this PR: mcr> This patch refactors the DTLSv1_listen() to create an mcr> alternative API that is called DTLSv1_accept(). mcr>

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

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

After noticing that a safecontents bag written to a file was in a different order than I added them, I did some experimentation and discovered that it's sorting the list, which led me to notice that it's defining a safecontentsbag as a SET OF safecontents, which causes sorting:

Re: [openssl-dev] NonStop platform support

On January 9, 2018 10:10 AM, Richard Levitte wrote: > On Jan 2018 09:32:25 -0500, "Randall S. Becker" said: > > rsbecker> A request, maybe OT. The NonStop platform does broadly deploy > rsbecker> Apache but do use OpenSSL. I understand that OpenSSL does not > rsbecker>

[openssl-dev] OpenSSL wins the Levchin prize

Today I have had great pleasure in attending the Real World Crypto 2018 conference in Zürich in order to receive the Levchin prize on behalf of the OpenSSL team. More details are available in my blog post here: https://www.openssl.org/blog/blog/2018/01/10/levchin/ Matt -- openssl-dev mailing

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

On Tue 2018-01-09 18:41:25 -0800, William Bathurst wrote: > [ dkg wrote: ] >> My understanding is that the algorithm designers and primary advocates >> have not been particularly forthcoming with their design goals, and >> their reputation is mixed, at best. > > Simon and Speck has been in the

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

On 9. jan. 2018, at 7:40 f.h., Randall S. Becker wrote: > On January 9, 2018 10:05 AM, Rich Salz wrote: >> It would be interesting to see how many changes you need to support your >> platform. > > Surprisingly not many at all. The platform has been significantly

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

Hi Dmitry, We implemented it using the same means as we saw the other ciphers. It was using the EVP functions. This way it could be included or excluded via makefile. Regards, Bill On 1/9/2018 12:23 AM, Dmitry Belyavsky wrote: Dear William, Does SPECK implementation need to be a part of

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

Hi dkg, You stated the following: My understanding is that the algorithm designers and primary advocates have not been particularly forthcoming with their design goals, and their reputation is mixed, at best. Simon and Speck has been in the public domain for a number of years and there are

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

Thank so much for your comment, Ben. We are planing to upgrade to the 1.1.0 branch as soon as we can which is not so easy to do at this moment as we need the FIPS capability. Thus, we are still focusing on the 1.0.2 release, and haven't had a chance to work on the 1.1.0 branch.  Thus, I won't

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

On 01/09/2018 01:47 PM, Misaki Miyashita wrote: > >>> Sorry, I meant to say it is for the 1.0.2 branch. >>> >> Except in exceptional circumstances, code only ends up in the 1.0.2 >> branch after having first gotten into the master branch and then the >> 1.1.0 branch.  The current release policy

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

Sorry, I meant to say it is for the 1.0.2 branch. Except in exceptional circumstances, code only ends up in the 1.0.2 branch after having first gotten into the master branch and then the 1.1.0 branch.  The current release policy only allows bug fixes to be backported to the stable branches,

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

On Monday, 8 January 2018 22:10:07 CET William Bathurst wrote: > Hi Hanno/all, > > I can understand your view that "more is not always good" in crypto. The > reasoning behind the offering can be found in the following whitepaper: > >

Re: [openssl-dev] NonStop platform support

On January 9, 2018 10:10 AM, Richard Levitte wrote: > In message <002801d38956$aec22c30$0c468490$@nexbridge.com> on Tue, > 9 Jan 2018 09:32:25 -0500, "Randall S. Becker" > said: > > rsbecker> A request, maybe OT. The NonStop platform does broadly deploy > rsbecker> Apache

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

On January 9, 2018 10:05 AM, Rich Salz wrote: > It would be interesting to see how many changes you need to support your > platform. Surprisingly not many at all. The platform has been significantly modernized since early ports. Most of the differences are the addition of a FLOSS layer (though

[openssl-dev] NonStop platform support

In message <002801d38956$aec22c30$0c468490$@nexbridge.com> on Tue, 9 Jan 2018 09:32:25 -0500, "Randall S. Becker" said: rsbecker> A request, maybe OT. The NonStop platform does broadly rsbecker> deploy Apache but do use OpenSSL. I understand that OpenSSL rsbecker> does

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

On January 9, 2018 9:46 AM Benjamin Kaduk wrote: > To: openssl-dev@openssl.org; Randall S. Becker > On 01/09/2018 08:32 AM, Randall S. Becker wrote: > > On January 9, 2018 8:41 AM, Rich Salz > >> ➢ We are currently modifying the source from Apache to OpenSSL open > >>

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

On 01/09/2018 08:32 AM, Randall S. Becker wrote: > On January 9, 2018 8:41 AM, Rich Salz >> ➢ We are currently modifying the source from Apache to OpenSSL open >> source >> licensing for the Speck/OpenSSL integration. Related repositories such >> as the cipher itself will remain under the

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

On January 9, 2018 8:41 AM, Rich Salz > ➢ We are currently modifying the source from Apache to OpenSSL open > source > licensing for the Speck/OpenSSL integration. Related repositories such > as the cipher itself will remain under the Apache license. We would love > input on the

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

On 01/09/2018 12:53 AM, Misaki Miyashita wrote: > > > On 01/ 8/18 04:46 PM, Misaki Miyashita wrote: >> (switching the alias to openssl-dev@openssl.org) >> >> I would like to suggest the following fix so that a valid certificate >> at .x can be recognized during the cert validation even when >> .0

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] Speck Cipher Integration with OpenSSL

Hi, I'm not particularly convinced. On Mon, 8 Jan 2018 13:10:07 -0800 William Bathurst wrote: > I will summarize in a different way though. We wish to offer an > optimized lightweight TLS for IoT. A majority of devices found in IoT > are resource constrained, for example

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

Dear William, Does SPECK implementation need to be a part of the OpenSSL bundle itself? It can be added as engine, similar to Russian GOST support, with minimal patches providing OIDs/NIDs if necessary. On Fri, Jan 5, 2018 at 9:52 PM, William Bathurst wrote: > Hello All, >

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

I think being able to interoperate with IoT devices using SPECK is a good idea. I'd like to know what kind of key exchange is likely to be used there. Regards, Uri Sent from my iPhone > On Jan 9, 2018, at 04:58, Richard Levitte wrote: > > I'm not terribly savvy regarding

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

On 01/ 8/18 04:46 PM, Misaki Miyashita wrote: (switching the alias to openssl-dev@openssl.org) I would like to suggest the following fix so that a valid certificate at .x can be recognized during the cert validation even when .0 is linking to a bad/expired certificate. This may not be the

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

I'm not terribly savvy regarding IoT, but I imagine that they do talk to something bigger. A server end, perhaps? What do we expect to run on that end? What happens, in that case, if SPECK makes its way into the TLS cipher suites? Would it be interesting to have OpenSSL interop with such

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

I'm wondering if one of the more specialised embedded cryptographic toolkits mightn't be a better option for your lightweight IoT TLS stack. There is a wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others. All of them claim to

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

(switching the alias to openssl-dev@openssl.org) I would like to suggest the following fix so that a valid certificate at .x can be recognized during the cert validation even when .0 is linking to a bad/expired certificate. This may not be the most elegant solution, but it is a minimal

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

On 01/08/2018 03:10 PM, William Bathurst wrote: > Hi Hanno/all, > > I can understand your view that "more is not always good" in crypto. > The reasoning behind the offering can be found in the following > whitepaper: > >

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

Hi Hanno/all, I can understand your view that "more is not always good" in crypto. The reasoning behind the offering can be found in the following whitepaper: https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf I will

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

Hi Bill-- On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote: > We have open sourced our work in regards to integrating the Speck Cipher > with OpenSSL. Basic information about this cipher can be found here. > > https://en.wikipedia.org/wiki/Speck_(cipher) >

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

On Fri, 5 Jan 2018 10:52:01 -0800 William Bathurst wrote: > 1) Community interest in such a lightweight cipher. I think there's a shifting view that "more is not always good" in crypto. OpenSSL has added features in the past "just because" and it was often a bad decision.

[openssl-dev] DTLS "accept" functionality

I have been working since mid-November in my "copious spare time" to bring DTLS support into ruby-openssl in order to bring DTLS into the Rails "David" CoAP server. DTLS_listen() seems entirely focused on single-use situations like in RTP, where only a single connection (single DTLS session) is

[openssl-dev] Speck Cipher Integration with OpenSSL

Hello All, We have open sourced our work in regards to integrating the Speck Cipher with OpenSSL. Basic information about this cipher can be found here. https://en.wikipedia.org/wiki/Speck_(cipher) SPECK is a lightweight block ciphers each

[openssl-dev] FIPS_mode_set - failed - SSLEAY_RAND_BYTES:PRNG not seeded

Hi All, Need your inputs on below issue: When I try to set the FIPS mode, seeing below error and failure intermittently: Error: FIPS_mode_set(1) failed. Reason: error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded I am using following versions: openssl-1.0.2k

Re: [openssl-dev] weird loop in s3_lib.c

Michael Richardson wrote: > in > const SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt, > STACK_OF(SSL_CIPHER) *srvr) never mind. I mis-read the brackets. -- ] Never tell me the odds! | ipv6 mesh networks [ ]

[openssl-dev] weird loop in s3_lib.c

in const SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt, STACK_OF(SSL_CIPHER) *srvr) we have: for (i = 0; i < sk_SSL_CIPHER_num(prio); i++) { c = sk_SSL_CIPHER_value(prio, i); ... if (!ok)

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

  1   2   3   4   5   6   7   8   9   10   >