[openssl-dev] Default installation of OpenSSL

[Dmitry Belyavsky]

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 such file or directory

$ ldd /usr/local/bin/openssl
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found

This behavior differs from the one for version 1.1.0b, where everything
works fine. Is this changed behavior intended?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
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

[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

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

[Kurt Roeckx]

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

Please open a pull request on github.


Kurt

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

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

[Atul Gupta]

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 (1):
  AFALG: Support AES-GCM for keysize 128,192,256

 engines/e_afalg.c | 568 --
 engines/e_afalg.h |  28 ++-
 engines/e_afalg_err.h |   2 +
 3 files changed, 578 insertions(+), 20 deletions(-)

-- 
1.8.3.1

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

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

[Atul Gupta]

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 --
 engines/e_afalg.h |  28 ++-
 engines/e_afalg_err.h |   2 +
 3 files changed, 578 insertions(+), 20 deletions(-)

diff --git a/engines/e_afalg.c b/engines/e_afalg.c
index 49b0173..b2de6bb 100644
--- a/engines/e_afalg.c
+++ b/engines/e_afalg.c
@@ -80,13 +80,18 @@ static int afalg_destroy(ENGINE *e);
 static int afalg_init(ENGINE *e);
 static int afalg_finish(ENGINE *e);
 const EVP_CIPHER *afalg_aes_cbc(int nid);
-static cbc_handles *get_cipher_handle(int nid);
+const EVP_CIPHER *afalg_aes_gcm(int nid);
+static aes_handles *get_cipher_handle(int nid);
 static int afalg_ciphers(ENGINE *e, const EVP_CIPHER **cipher,
  const int **nids, int nid);
 static int afalg_cipher_init(EVP_CIPHER_CTX *ctx, const unsigned char *key,
  const unsigned char *iv, int enc);
 static int afalg_do_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
const unsigned char *in, size_t inl);
+static int afalg_gcm_init(EVP_CIPHER_CTX *ctx, const unsigned char *key,
+ const unsigned char *iv, int enc);
+static int afalg_do_gcm(EVP_CIPHER_CTX *ctx, unsigned char *out,
+   const unsigned char *in, size_t inl);
 static int afalg_cipher_cleanup(EVP_CIPHER_CTX *ctx);
 static int afalg_chk_platform(void);
 
@@ -98,11 +103,17 @@ static int afalg_cipher_nids[] = {
 NID_aes_128_cbc,
 NID_aes_192_cbc,
 NID_aes_256_cbc,
+NID_aes_128_gcm,
+NID_aes_192_gcm,
+NID_aes_256_gcm,
 };
 
-static cbc_handles cbc_handle[] = {{AES_KEY_SIZE_128, NULL},
-{AES_KEY_SIZE_192, NULL},
-{AES_KEY_SIZE_256, NULL}};
+static aes_handles cipher_handle[] = {{AES_KEY_SIZE_128, NULL},
+  {AES_KEY_SIZE_192, NULL},
+  {AES_KEY_SIZE_256, NULL},
+  {AES_KEY_SIZE_128, NULL},
+  {AES_KEY_SIZE_192, NULL},
+  {AES_KEY_SIZE_256, NULL}};
 
 static ossl_inline int io_setup(unsigned n, aio_context_t *ctx)
 {
@@ -324,6 +335,129 @@ int afalg_fin_cipher_aio(afalg_aio *aio, int sfd, 
unsigned char *buf,
 return 1;
 }
 
+int afalg_fin_gcm_aio(EVP_CIPHER_CTX *ctx, int sfd, unsigned char *buf,
+   size_t len)
+{
+afalg_gcm_ctx *gctx;
+afalg_ctx *actx;
+afalg_aio *aio;
+int retry = 0;
+unsigned int done = 0;
+struct iocb *cb;
+struct timespec timeout;
+struct io_event events[MAX_INFLIGHTS];
+struct iovec iov[2];
+u_int64_t eval = 0;
+int r;
+
+timeout.tv_sec = 0;
+timeout.tv_nsec = 0;
+gctx = (afalg_gcm_ctx *) EVP_CIPHER_CTX_get_cipher_data(ctx);
+actx = (afalg_ctx *)>ctx;
+aio = >aio;
+
+/* if efd has not been initialised yet do it here */
+if (aio->mode == MODE_UNINIT) {
+r = afalg_setup_async_event_notification(aio);
+if (r == 0)
+return 0;
+}
+
+cb = &(aio->cbt[0 % MAX_INFLIGHTS]);
+memset(cb, '\0', sizeof(*cb));
+
+/* iov that describes input data */
+iov[0].iov_base = (void *)EVP_CIPHER_CTX_buf_noconst(ctx);
+iov[0].iov_len = gctx->aad_len;
+iov[1].iov_base = (unsigned char *)buf;
+iov[1].iov_len = len;
+
+cb->aio_fildes = sfd;
+cb->aio_lio_opcode = IOCB_CMD_PREADV;
+/*
+ * The pointer has to be converted to unsigned value first to avoid
+ * sign extension on cast to 64 bit value in 32-bit builds
+ */
+cb->aio_buf = (size_t)iov;
+cb->aio_offset = 0;
+cb->aio_data = 0;
+cb->aio_nbytes = 2;
+cb->aio_flags = IOCB_FLAG_RESFD;
+cb->aio_resfd = aio->efd;
+
+/*
+ * Perform AIO read on AFALG socket, this in turn performs an async
+ * crypto operation in kernel space
+ */
+r = io_read(aio->aio_ctx, 1, );
+if (r < 0) {
+ALG_PWARN("%s: io_read failed : ", __func__);
+return 0;
+}
+
+do {
+/* While AIO read is being performed pause job */
+ASYNC_pause_job();
+
+/* Check for completion of AIO read */
+r = read(aio->efd, , sizeof(eval));
+if (r < 0) {
+if (errno == EAGAIN || errno == EWOULDBLOCK)
+continue;
+ALG_PERR("%s: read failed for event fd : ", __func__);
+return 0;
+} else if (r == 0 || eval <= 0) {
+ALG_WARN("%s: eventfd read %d bytes, eval = %lu\n", __func__, r,
+ eval);
+}
+if (eval > 0) {
+
+/* Get results of AIO read */
+r = io_getevents(aio->aio_ctx, 1, MAX_INFLIGHTS,
+   

Re: [openssl-dev] GCM for AFALG engine

[Matt Caswell]

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 you have read the CONTRIBUTING file in the top
level dir.

> 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, 192 and 256 key size

As this is a new feature it should target the master branch. Please note
that master already has support for 192 and 256 AES-CBC.

Matt

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

[openssl-dev] GCM for AFALG engine

[Atul Gupta]

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, 192 and 256 key size

Thanks
Atul
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Viktor Dukhovni]

> 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 misplaced user questions.  Technical
topics related to the future evolution of OpenSSL should I think be
open for discussion on this list if they're not yet sufficiently
well formulated for tracking as a GitHub issue.  These might be design
ideas, clarification of requirements, ...  The point being that mailing
lists are good for *discussion* and Github is not particularly well
suited for that.

-- 
Viktor.

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

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

[Richard Levitte]

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> > openssl-dev.
openssl-users> 
openssl-users> Well, but we now have "openssl-project" for discussions
openssl-users> of the ongoing development of OpenSSL.  It is mostly
openssl-users> for team members, but though it is moderated, IIRC
openssl-users> others can join and post.

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

>From the blog entry:

> We created a new mailing list, openssl-project, that is for
> discussions about the governance and policies of OpenSSL. Anyone can
> join this list. Only members of the OMC and committers will be able
> to post.

Governance and policies (roughly speaking, 'cause there may be some
derailing that's shouldn't be there) is not, as far as I understand,
"development of OpenSSL".  It may be close, thought, such as planning
the schedule of the next release.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
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

[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 "unsafe". There needs to be 
at least a little bit of guidance.

Pedantically and strictly speaking, you might be correct.  Pragmatically, 
however, many people have been able to write or deploy multi-threaded servers.

I doubt that anyone on the project will do anything approaching a definitive 
thread-safety analysis, let alone documentation.  Even with the “small number 
of API’s” that might be affected.


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

[Wim Lewis]

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 has much interest 
>> in fixing 1.0.2 locking issues.
> 
> Who said they were 1.0.2-specific?  Master's obj_dat.c still has a completely 
> unlocked OBJ_new_nid() that is a public API function; AFAICT the issue is 
> still present.

As you say, this really doesn't seem to be a 1.0.x-specific problem. The 
current development tip on github has the same issue (and the same language in 
doc/man3/CRYPTO_THREAD_run_once.pod).

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 "unsafe". There needs to be 
at least a little bit of guidance.

A quick check of my system's openssl 1.1 libraries shows 280 mutable global 
variables in libcrypto and 36 in libssl. Most of those are presumably protected 
by locks or are only set during init; for the remaining actual thread-unsafe 
variables, it should be possible to document the small number of APIs which 
affect them.


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

[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.openssl.org/mailman/listinfo/openssl-dev

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

[Michael Richardson]

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
> discussion, while Github et. al. are for issue tracking.

> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.

I'm okay with taking more of the "what is the right answer" questions to
openssl-users if that's the plan.

I truly love github for many many things, but the email interface to issues
and pull requests has been a problem for me with projects like tcpdump.
I personally don't render HTML parts, and read 90% of my email via
emacsclient -nw.

Users reasonably post things. 60% are silly requests which a google search or
a "man foo" would resolve but it generates emails to the busiest people
only (the maintainers), skipping the other users on the list who *also* could
answer if they knew there was a well formed question.

Is there a stackexchange/serverfault?

I took to CC: tcpdump-workers when I answered github issues by email,
particularly when there was a question of project goals or policy involved.
I realized that there is a bit of a XSS/spam attack facilitated by doing that
as the magic reply-to address to get stuff posted to the github issue is now
happily archived in the ML!

Does github issue process the emails with useful quoting in them usefully? 
Sorta.
So, I'm skeptical, but I am willing to go with the plan.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Viktor Dukhovni]

> 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 will be more focused
> and not bothered with so many misplaced posts that should have
> gone to openssl-users.

Interested participants can sign up at:

  https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Viktor.

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

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

[Dr. Matthias St. Pierre]

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 on GitHub can
join the moderated openssl-project list then this sounds like a good
replacement for openssl-dev, because that list will be more focused
and not bothered with so many misplaced posts that should have
gone to openssl-users.

Matthias

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

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

[Viktor Dukhovni]

> 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 subjects, whereas
> openssl-dev was for discussion around the development process itself.

Where "development process" means development of OpenSSL itself, not
software dependent on OpenSSL.  Since openssl is primarily a developer
toolkit, not end-user software, the openssl-users list is really for
developers, just not developers of OpenSSL itself.

> If we agree that mailing lists are preferrable to GitHub threads, then we
> should not close down openssl-dev.

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.

> Because openssl-project is readonly for most developers

s/developers/users/

> and I don't think it would be a good idea to join openssl-dev
> and openssl-users.

Well, I've been on both for a long time, and mostly find that
I wish the openssl-dev posts were on openssl-users instead,
they really mostly aren't about ongoing OpenSSL development.

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

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

[Steffen Nurpmeso]

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
 |discussion, while Github et. al. are for issue tracking.
 |
 |If there's a clear problem that requires tracking and resolution,
 |then the right forum is Github.  If there's a topic to discuss,
 |we have openssl-users.  Most openssl-dev threads were more
 |appropriate for openssl-users.

I see an overwhelming amount of posts on the new list which where
somehow missed on -dev, though.

As a general note that you might not know, from Germany at least
and over my internet account and being not a logged in user i find
that github very often fails to generate commit data or cuts
directory listings.  At least there are no advertisings which
consume multiple CPUs for who-knows-what.

 |So I'm not convinced we need two free-form discussion lists, but
 |concur that if it is discussion one wants, then email clearly
 |superior to Github issue tracking.  The key question is whether
 |openssl-users suffices to meet that need.

Oh, -dev was a terribly noisy list.  So: ch-ch-ch-ch-changes
(turn and face the strange).

Congratulations for the price you have won.  Especially so in
respect to, brave new world!, having to go over browser based
issue tracker interfaces.  I could not do that.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Matthias St. Pierre]

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
> discussion, while Github et. al. are for issue tracking.
>
> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.
>
> So I'm not convinced we need two free-form discussion lists, but
> concur that if it is discussion one wants, then email clearly
> superior to Github issue tracking.  The key question is whether
> openssl-users suffices to meet that need.
>

Although GitHub issues provide nice features like markdown and
syntax highlighting, I agree with Viktor that in general mailing lists are
much more suitable for general discussion. If nothing else, then because
they are open for everyone to read and search (via the mail archives)
and don't require a login.

So IMHO GitHub issues should remain for topics like bug reports and
specific discussions related to current pull requests.

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 subjects, whereas
openssl-dev was for discussion around the development process itself.
If we agree that mailing lists are preferrable to GitHub threads, then we
should not close down openssl-dev. Because openssl-project is readonly
for most developers and I don't think it would be a good idea
to join openssl-dev and openssl-users.

Matthias

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

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

[Viktor Dukhovni]

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

If there's a clear problem that requires tracking and resolution,
then the right forum is Github.  If there's a topic to discuss,
we have openssl-users.  Most openssl-dev threads were more
appropriate for openssl-users.

So I'm not convinced we need two free-form discussion lists, but
concur that if it is discussion one wants, then email clearly
superior to Github issue tracking.  The key question is whether
openssl-users suffices to meet that need.

-- 
Viktor.

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

[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

[Yun Jiang]

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 by OID.

Yun

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, 
Rich via openssl-dev
Sent: 24 January 2018 14:40
To: openssl-dev@openssl.org
Subject: 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 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 January 2018 01:23
To: Salz, Rich >; 
openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:"Salz, Rich via openssl-dev" 
>
To:"openssl-dev@openssl.org" 
>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


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.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=


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

[Salz, Rich via openssl-dev]

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 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 January 2018 01:23
To: Salz, Rich ; openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:"Salz, Rich via openssl-dev" 
>
To:"openssl-dev@openssl.org" 
>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


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.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=



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

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

[Michael Richardson]

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 takes ten times as long as it does when using
> email

+1

> email clients are designed to handle hundreds to thousands of messages
> a day, Github UI isn't



signature.asc
Description: PGP signature
-- 
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

[Benjamin Kaduk via openssl-dev]

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
> 
> )
>
>  
>
>   * "OpenSSL can safely be used in multi-threaded applications
> provided that at least two callback functions are set,
> locking_function and threadid_func."
>
>  
>
>   * Is there any planning to fix this issue?
>
>  
>
>  
>
> 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.
>
>

Who said they were 1.0.2-specific?  Master's obj_dat.c still has a
completely unlocked OBJ_new_nid() that is a public API function; AFAICT
the issue is still present.

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

[Yun Jiang]

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 January 2018 01:23
To: Salz, Rich ; openssl-dev@openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that 
after threading has started is not going to give good results with or without 
locking.

Peter




From:"Salz, Rich via openssl-dev" 
>
To:"openssl-dev@openssl.org" 
>
Date:24/01/2018 11:19
Subject:Re: [openssl-dev] About multi-thread unsafe for APIs defined in 
crypto/objects/obj_dat.c
Sent by:"openssl-dev" 
>



  *   OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


  *   "OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


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.--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=


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

[Yun Jiang]

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 APIs, which makes the following OpenSSL documentation statement 
invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


Ø  "OpenSSL can safely be used in multi-threaded applications provided that at 
least two callback functions are set, locking_function and threadid_func."


Ø  Is there any planning to fix this issue?





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.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Yun Jiang]

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 APIs, which makes the 
following OpenSSL documentation statement invalid 
(https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


"OpenSSL can safely be used in multi-threaded applications provided that at 
least two callback functions are set, locking_function and threadid_func."


Is there any planning to fix this issue?


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

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

[Florian Weimer]

* 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 for some of
us, but that is perhaps our own fault.)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Levitte]

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 gmane.comp.encryption.openssl.project as readonly list.
openssl-dev>   
openssl-dev> I will always have a fondness for NNTP :)

...  except for the trashing of the database disk(s) back in the days
if you're running a server...  (I did)  (on VMS ;-))

But yeah, totally agree otherwise

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario]

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 disabled because I use the same account for both my 
personal and my work projects so no single email address is correct for them

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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/openssl-dev

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

[Dr. Matthias St. Pierre]

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 followed I'm getting only 
> messages 
> from that issue/PR
>
> when I mark project as followed I'm getting messages from all issues and all 
> PRs - likely dozens if not hundred messages a day

Have you checked Github > Settings > Emails > Email preferences ? 
Maybe yours are set to "Receive all emails"?

My settings are as follows:

   ( )  Receive all emails, except those I unsubscribe from.

   (*) Only receive account related emails, and those I subscribe to.

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

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

[Hubert Kario]

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 issue/PR

when I mark project as followed I'm getting messages from all issues and all 
PRs - likely dozens if not hundred messages a day

> 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 what you see as different?

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 takes ten times as long as it does when using email

email clients are designed to handle hundreds to thousands of messages a day, 
Github UI isn't

or to put it other way: github notifications are perfect if you are directly 
involved in the project, they suck if you just want to keep tabs on an active 
project
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

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

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

[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 what you see as different?

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

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

[Hubert Kario]

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, "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 GitHub. In addition to asking that
> > all bug
> > reports and enhancement requests be reported as issues, we
> > now want all major code proposals to be discussed as issues before a
> > large pull request shows up. This will let the community discuss the
> > feature, offer input on design and such, before having code to look
> > at. We hope this will let us all first look at the bigger picture,
> > before getting bogged down in the weeds of line-by-line code reviews.
> 
> 
> does that mean I have to subscribe to all notifications from the openssl
> 
> github project to notice them? that's really suboptimal
> 
> -- 
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
> 


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Jan Ehrhardt]

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 list.
-- 
Jan

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

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

[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.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 issues, we now want all
> major code proposals to be discussed as issues before a large pull request
> shows up. This will let the community discuss the feature, offer input on
> design and such, before having code to look at. We hope this will let us
> all first look at the bigger picture, before getting bogged down in the
> weeds of line-by-line code reviews.

does that mean I have to subscribe to all notifications from the openssl 
github project to notice them? that's really suboptimal

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

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

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

[Dmitry Belyavsky]

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 GitHub. In addition to asking that all
> bug
> > reports and enhancement requests be reported as issues, we now want all
> > major code proposals to be discussed as issues before a large pull
> request
> > shows up. This will let the community discuss the feature, offer input on
> > design and such, before having code to look at. We hope this will let us
> > all first look at the bigger picture, before getting bogged down in the
> > weeds of line-by-line code reviews.
>
> does that mean I have to subscribe to all notifications from the openssl
> github project to notice them? that's really suboptimal
>

Totally agree.


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hubert Kario]

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 issues, we now want all
> major code proposals to be discussed as issues before a large pull request
> shows up. This will let the community discuss the feature, offer input on
> design and such, before having code to look at. We hope this will let us
> all first look at the bigger picture, before getting bogged down in the
> weeds of line-by-line code reviews.

does that mean I have to subscribe to all notifications from the openssl 
github project to notice them? that's really suboptimal

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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
>   to make it very clear that this is a new way of operating, and 
> openssl-project is a
>   moderated list.  Make sense?

I don’t know. I’d still do as I said. But since you guys discussed it (i.e., 
debated this option), I’ll defer to your judgment.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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-project is a moderated list.  Make sense?

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

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

[Blumenthal, Uri - 0553 - MITLL]

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" 
 wrote:

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 project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who 
uses OpenSSL.  Thanks for your interest, and all your efforts to help improve 
the project!



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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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 project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who uses 
OpenSSL.  Thanks for your interest, and all your efforts to help improve the 
project!



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

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

[Matt Caswell]

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 BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
> > ctrls should return an error on platforms that we don't know we can
> > support, i.e. attempt to detect (at compile time) whether we are on a
> > platform that we know has the required system calls - if we are then use
> > them, otherwise we do things the old way.
> 
> > Note that stuff like this is problematic:
> 
> > char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> > in_pktinfo))];
> 
> > The "attribute" is compiler specific and not something we can rely on to
> > be available. Additionally "CMSG_SPACE" is probably not portable, and in
> > any case may not evaluate to a compile time constant (according to the
> > man page), so this is not C90 (which is a requirement for OpenSSL
> > submissions).
> 
> Understood.
> I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.
> 
> What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
> A bunch of #ifdef on OS definitions?

If its non portable and we're not already using it then that's the
probably the best we can do. We should try and provide some sensible
fallback wherever possible. Or if not possible it shouldn't break
anything that already works.

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

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

[Michael Richardson]

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 error on platforms that we don't know we can
> support, i.e. attempt to detect (at compile time) whether we are on a
> platform that we know has the required system calls - if we are then use
> them, otherwise we do things the old way.

> Note that stuff like this is problematic:

> char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> in_pktinfo))];

> The "attribute" is compiler specific and not something we can rely on to
> be available. Additionally "CMSG_SPACE" is probably not portable, and in
> any case may not evaluate to a compile time constant (according to the
> man page), so this is not C90 (which is a requirement for OpenSSL
> submissions).

Understood.
I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.

What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
A bunch of #ifdef on OS definitions?

> Once this PR is in (assuming it gets accepted), then you can look at
> what remains of your original PR and see if it makes sense to raise new
> PRs to bring the rest of it in.

Roger. Wilco.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

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

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

[Matt Caswell]

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 get our own address. You could then call that immediately after a
> > successful DTLSv1_listen() call. Obviously we'd have to change the
> > dgram BIO to use recvmsg for this to work.
> 
> That's here:
>
> https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
>
> https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
> and:   
> https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323

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 error on platforms that we don't know we can
support, i.e. attempt to detect (at compile time) whether we are on a
platform that we know has the required system calls - if we are then use
them, otherwise we do things the old way.

Note that stuff like this is problematic:

char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
in_pktinfo))];

The "attribute" is compiler specific and not something we can rely on to
be available. Additionally "CMSG_SPACE" is probably not portable, and in
any case may not evaluate to a compile time constant (according to the
man page), so this is not C90 (which is a requirement for OpenSSL
submissions).

I suggest you Configure with the "--strict-warnings" option which will
probably complain about some of this stuff.

Please also make sure we have suitable documentation and ideally tests too.

Once this PR is in (assuming it gets accepted), then you can look at
what remains of your original PR and see if it makes sense to raise new
PRs to bring the rest of it in.

Matt

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

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

[Kurt Roeckx]

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 AEAD API [...]"
> https://www.openssl.org/policies/roadmap.html#forthcoming
> 
> Was this already evaluated? If yes, what was the result ?

Nobody has had time for this, feel free to make a proposal.


Kurt

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

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

[Michael Richardson]

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 to >> open a new socket
>> >> first.  The application can do this two ways: it can >> open a new
>> >> socket on which to receive new connections, or it can open >> a new
>> >> socket on which to communicate with the new client.  The second >>
>> >> method is better for reason (b) below.  Either way, it socket to >>
>> >> communicate with the client needs to be bind(2) to the address that >>
>> >> the client used to communicate with the server, and DTLSv1_listen() >>
>> >> didn't collect or return that information.
>> >>
>> >> > The second way is what is intended.
>> >>
>> >> Unfortunately, there remains a race condition because we have to call
>> >> bind() before connect() on the new socket.  Under load, if a packet is
>> >> received between the bind() and the connect(), it might go onto the
>> >> wrong socket queue. So some packets that could have been processed
>> >> will get dropped and have to be retransmitted by the client.
>>
>> > This seems like a non-issue to me. At this point in the handshake the
>> > client will have sent its ClientHello and won't progress until it gets
>> > the server's flight back (ServerHello etc), i.e. in the vast majority
>> > of cases it won't be sending anything.
>>
>> *That* client will be waiting, but other clients may be sending new 
ClientHello
>> messages (with or without cookies).

> So how does your refactor solve this issue? AFAICT this also just does a
> bind then connect:

My refactor does not solve it. I'm noting that this is still an issue.

It's not solvable unless the kernel can do both operations at the same time,
for which there isn't a standard call (nor a non-standard one).
If we could punt segments between BIOs easily, then we could deal with the
problem, but I don't think it's worth solving.


> if(bind(rfd,BIO_ADDR_sockaddr(ouraddr),BIO_ADDR_sockaddr_size(ouraddr))
> != 0){
> +  goto end;
> +}
> +
> if(connect(rfd,BIO_ADDR_sockaddr(client),BIO_ADDR_sockaddr_size(client))
> != 0) {
> +  goto end;
> +}

> Doesn't this suffer from the same problem? i.e. packets could arrive
> from other clients between the bind and connect.

Yes.

This is in contrast this situation to the original problem with connect()'ing
the socket which is given to DTLSv1_listen(). That socket has lots of time
between the two points in which to accumulate new connection requests.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Patrick Steuer]

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


Ctrls for 1-shot aead paket processing like in tls 1.2 would be the 
easiest solution for tls 1.3 pakets and i agree it could also be 
extended to the general case.


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 AEAD API [...]"
https://www.openssl.org/policies/roadmap.html#forthcoming

Was this already evaluated? If yes, what was the result ?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Peter Waltenberg]

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 
To: openssl-dev 
Date:   18/01/2018 04:10
Subject:[openssl-dev] evp cipher/digest - add alternative to 
init-update-final interface
Sent by:"openssl-dev" 



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. This
leads to more functions than necessary needing to be called to
process a single paket (user errors). It is also a small paket
performance problem for (possibly engine provided) hardware
implementations for which it enforces a superfluous call to a
coprocessor or adapter.

libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
layer encryption by passing additional context information via the
control interface and calling EVP_Cipher (undocumented, no engine
support. The analoguously named, undocumented EVP_Digest is just an
init-update-final wrapper). The same would be possible for tls 1.3
pakets (it is currently implemented using init-update-final and
performs worse than tls 1.2 record encryption on some s390 hardware).

I would suggest to add (engine supported) interfaces that can process a
paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
primitives that are often used in a non-streaming context, like aead
constructions in modern tls (This would also make it possible to move
tls specific code like nonce setup to libssl. Such interfaces already
exist in boringssl[1] and libressl[2]).

What do you think ?

Best,
Patrick

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__commondatastorage.googleapis.com_chromium-2Dboringssl-2Ddocs_aead.h.html=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=upMfA8eZGxh6kmIwqjO38Chm2MNi_BocHjrm84jCvOU=

[2] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__man.openbsd.org_EVP-5FAEAD-5FCTX-5Finit=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=YXrque0c5mOqsKzVMjt2T5m4mIcgo3GVThIqnGLJeRo=

-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=-TsrGPSFfFkhWasxuHDt19pNsDGsEW3BQp19rT507Xw=






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

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

[Benjamin Kaduk via openssl-dev]

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
> operation must be "artificially" split between update/final. This
> leads to more functions than necessary needing to be called to
> process a single paket (user errors). It is also a small paket
> performance problem for (possibly engine provided) hardware
> implementations for which it enforces a superfluous call to a
> coprocessor or adapter.
>
> libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
> layer encryption by passing additional context information via the
> control interface and calling EVP_Cipher (undocumented, no engine
> support. The analoguously named, undocumented EVP_Digest is just an
> init-update-final wrapper). The same would be possible for tls 1.3
> pakets (it is currently implemented using init-update-final and
> performs worse than tls 1.2 record encryption on some s390 hardware).
>
> I would suggest to add (engine supported) interfaces that can process a
> paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
> primitives that are often used in a non-streaming context, like aead
> constructions in modern tls (This would also make it possible to move
> tls specific code like nonce setup to libssl. Such interfaces already
> exist in boringssl[1] and libressl[2]).
>
> What do you think ?

The one-shot EVP_DigestSign() and EVP_DigestVerify() APIs were added to
support the PureEdDSA algorithm, which is incapable of performing
init/update/final signatures.  That seems like precedent for adding such
APIs for the other types of EVP functionality, though getting a
non-wrapper implementation that actually allows ENGINE implementations
would be some amount of work.

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

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

[Patrick Steuer]

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. This
leads to more functions than necessary needing to be called to
process a single paket (user errors). It is also a small paket
performance problem for (possibly engine provided) hardware
implementations for which it enforces a superfluous call to a
coprocessor or adapter.

libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
layer encryption by passing additional context information via the
control interface and calling EVP_Cipher (undocumented, no engine
support. The analoguously named, undocumented EVP_Digest is just an
init-update-final wrapper). The same would be possible for tls 1.3
pakets (it is currently implemented using init-update-final and
performs worse than tls 1.2 record encryption on some s390 hardware).

I would suggest to add (engine supported) interfaces that can process a
paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
primitives that are often used in a non-streaming context, like aead
constructions in modern tls (This would also make it possible to move
tls specific code like nonce setup to libssl. Such interfaces already
exist in boringssl[1] and libressl[2]).

What do you think ?

Best,
Patrick

[1] 
https://commondatastorage.googleapis.com/chromium-boringssl-docs/aead.h.html

[2] http://man.openbsd.org/EVP_AEAD_CTX_init
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Michael Richardson]

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 can do this two ways: it can >> open a new
>> socket on which to receive new connections, or it can open >> a new
>> socket on which to communicate with the new client.  The second >>
>> method is better for reason (b) below.  Either way, it socket to >>
>> communicate with the client needs to be bind(2) to the address that >>
>> the client used to communicate with the server, and DTLSv1_listen() >>
>> didn't collect or return that information.
>>
>> > The second way is what is intended.
>>
>> Unfortunately, there remains a race condition because we have to call
>> bind() before connect() on the new socket.  Under load, if a packet is
>> received between the bind() and the connect(), it might go onto the
>> wrong socket queue. So some packets that could have been processed
>> will get dropped and have to be retransmitted by the client.

> This seems like a non-issue to me. At this point in the handshake the
> client will have sent its ClientHello and won't progress until it gets
> the server's flight back (ServerHello etc), i.e. in the vast majority
> of cases it won't be sending anything.

*That* client will be waiting, but other clients may be sending new ClientHello
messages (with or without cookies).

>> The address of the remote client is returned ("getpeername()") by
>> DTLSv1_listen().  That's all that recvfrom() gives you.
>>
>> recvfrom() was a reasonable API for SunOS 3.x machines with a single
>> 10Mb/s interface with a single IPv4 address.  I loved all that at the
>> time...  But it doesn't work that well when we might have a dozen
>> different kind of IPv6 addresses on each virtual interface.
>>
>> The address that I'm talking about needing is the one the remote
>> client used to reach us.  That's the destination IP of the incoming
>> packet ("getsockname()" in TCP speak).

> Ahhhits the *server's* address you are after. This requirement
> seems more reasonable. I think the API is designed to expect you to
> only bind to a single IP. I'd be interested in Richard Levitte's
> opinion on this.

okay.
binding to a single IP is not scalable in many applications.

> 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 get our own address. You could then call that immediately after a
> successful DTLSv1_listen() call. Obviously we'd have to change the
> dgram BIO to use recvmsg for this to work.

That's here:
   
https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
   
https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
and:   
https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323


--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Tomas Mraz]

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 encoding rules)
> > 
> > 
> > 
> 
> Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a
> quick reference I found.  So that could be an interoperability
> concern.
>  But maybe this is the first actual use of nested safecontents, since
> this difference flew under the radar for so long :)

Would it be possible to allow for loading the safecontents bag with
both correct and incorrect tag? But we should always write the correct
one.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

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

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

[Blumenthal, Uri - 0553 - MITLL]

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 interop problems if we change it?  (I
>> don’t remember the DER encoding rules)
>> 
>> 
>> 
> 
> Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a
> quick reference I found.  So that could be an interoperability concern.
> But maybe this is the first actual use of nested safecontents, since
> this difference flew under the radar for so long :)
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

[Matt Caswell]

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 application can do this two ways: it can
> >> open a new socket on which to receive new connections, or it can open
> >> a new socket on which to communicate with the new client.  The second
> >> method is better for reason (b) below.  Either way, it socket to
> >> communicate with the client needs to be bind(2) to the address that
> >> the client used to communicate with the server, and DTLSv1_listen()
> >> didn't collect or return that information.
> 
> > The second way is what is intended.
> 
> Unfortunately, there remains a race condition because we have to call bind()
> before connect() on the new socket.  Under load, if a packet is received
> between the bind() and the connect(), it might go onto the wrong socket
> queue. So some packets that could have been processed will get dropped and
> have to be retransmitted by the client.

This seems like a non-issue to me. At this point in the handshake the
client will have sent its ClientHello and won't progress until it gets
the server's flight back (ServerHello etc), i.e. in the vast majority of
cases it won't be sending anything.

It is possible that the client may retransmit the ClientHello if the
server hasn't responded within a timely manner. Retransmit times are
usually quite a while (relatively speaking) after the original
transmission, so the chances of this happening immediately after we've
processed the original ClientHello and before we've called connect()
seem quite small - although possible. If a retransmitted ClientHello
arrives *after* the connect() it will be dropped anyway by OpenSSL so we
really don't care about these messages going missing.

Another possibility is that the client transmits an alert of some form.
This also seems quite unlikely (i.e. send a ClientHello and then
immediately send an alert before the server has had a chance to respond)
- but again, its possible. It would be bad luck indeed for this unlikely
scenario to happen and then for the alert to not make it onto the right
fd due to the race: but if it did its not a big deal. This connection is
doomed in any case (an alert was sent) and we have to be prepared to
deal with packets getting dropped anyway (this is DTLS!). It is very
common for clients to just abort without sending an alert anyway - so
this will just appear like that.

> 
> It could be solved if there was a way to punt packets received on the wrong
> socket to the correct BIO on the input side.  I looked into this, but decided
> it was too difficult...
> 
> That would also let one operate a multitude of DTLS connections using single
> socket which might be a boon to some users.  Mis-designed it would scale
> badly on multi-threaded machines and involve lots of ugly locks.
> I don't want to consider the impacts if one had to pass packets between 
> processes...
> I don't advocate a solution like this (I'll live with the dropped packets),
> but I think it's worth making people aware that they might see mis-directed
> packets get dropped.
> 
> > Maybe I misunderstand your point -
> > but the client address *is* returned? Admittedly its wrapped in a
> > BIO_ADDR, but its easy to get the underlying "raw" address using
> > BIO_ADDR_rawaddress():
> 
> > Why isn't recvfrom() suitable (which is what the code currently uses to
> > get the address)?
> 
> The address of the remote client is returned ("getpeername()") by 
> DTLSv1_listen().
> That's all that recvfrom() gives you.
> 
> recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
> interface with a single IPv4 address.  I loved all that at the time...
> But it doesn't work that well when we might have a dozen different kind of
> IPv6 addresses on each virtual interface.
> 
> The address that I'm talking about needing is the one the remote client used
> to reach us.  That's the destination IP of the incoming packet 
> ("getsockname()" in TCP speak).

Ahhhits the *server's* address you are after. This requirement seems
more reasonable. I think the API is designed to expect you to only bind
to a single IP. I'd be interested in Richard Levitte's opinion on this.

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 get our own address. You could then call that immediately after a
successful DTLSv1_listen() call. Obviously we'd have to change the dgram
BIO to use recvmsg for this to work.

Matt

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

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

[Michael Richardson]

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 on which to receive new connections, or it can open
>> a new socket on which to communicate with the new client.  The second
>> method is better for reason (b) below.  Either way, it socket to
>> communicate with the client needs to be bind(2) to the address that
>> the client used to communicate with the server, and DTLSv1_listen()
>> didn't collect or return that information.

> The second way is what is intended.

Unfortunately, there remains a race condition because we have to call bind()
before connect() on the new socket.  Under load, if a packet is received
between the bind() and the connect(), it might go onto the wrong socket
queue. So some packets that could have been processed will get dropped and
have to be retransmitted by the client.

It could be solved if there was a way to punt packets received on the wrong
socket to the correct BIO on the input side.  I looked into this, but decided
it was too difficult...

That would also let one operate a multitude of DTLS connections using single
socket which might be a boon to some users.  Mis-designed it would scale
badly on multi-threaded machines and involve lots of ugly locks.
I don't want to consider the impacts if one had to pass packets between 
processes...
I don't advocate a solution like this (I'll live with the dropped packets),
but I think it's worth making people aware that they might see mis-directed
packets get dropped.

> Maybe I misunderstand your point -
> but the client address *is* returned? Admittedly its wrapped in a
> BIO_ADDR, but its easy to get the underlying "raw" address using
> BIO_ADDR_rawaddress():

> Why isn't recvfrom() suitable (which is what the code currently uses to
> get the address)?

The address of the remote client is returned ("getpeername()") by 
DTLSv1_listen().
That's all that recvfrom() gives you.

recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
interface with a single IPv4 address.  I loved all that at the time...
But it doesn't work that well when we might have a dozen different kind of
IPv6 addresses on each virtual interface.

The address that I'm talking about needing is the one the remote client used
to reach us.  That's the destination IP of the incoming packet ("getsockname()" 
in TCP speak).

With TCP this is never an issue because the kernel creates the new socket and
copies the right stuff in for us when it creates the socket.

With UDP, the source address for outgoing packets needs to match or the
client may get a response from an address that it didn't connect to.  Worse,
there might be firewalls or policy routing that would cause the packet to
disappear or get routed differently.  In my application, I definitely dealing
with connections over IPv6 Link-Local addresses with a multitude of virtual
links.

In your code example:
bind(client_fd, _addr, sizeof(struct sockaddr_in6));

server_addr has to be set from the destination address of the incoming
packet, it's not a global that the admin set, or the SIP negotiated.

In the bad old days, this meant opening a socket for every interface on the
machine, and re-reading the list of interfaces based upon some heuristic.
(routing socket, SIGHUP, ...)

Even getting a list of interfaces (and their addresses) is itself a
OS-dependant activity!  And, if you use the old BSD interface on Linux,
you'll miss a bunch of interfaces, because the Linux kernel people thought
that it would confuse BSD APIs if interfaces were returned that the BSD
interface didn't create.  So you can't even win there.

The IPv6 API gives us recvmsg() and ipi6_pktinfo, which makes it all sane.
But, we never got a standard interface for IPv4: Linux uses something that
looks identical to IPv6, and BSD has something with slightly different names.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Sands, Daniel]

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 uses tag 17, according to a
quick reference I found.  So that could be an interoperability concern.
 But maybe this is the first actual use of nested safecontents, since
this difference flew under the radar for so long :)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell]

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 which to 
> receive
>new connections, or it can open a new socket on which to communicate with
>the new client.The second method is better for reason (b) below.
>Either way, it socket to communicate with the client needs to be bind(2)
>to the address that the client used to communicate with the server, and
>DTLSv1_listen() didn't collect or return that information.

The second way is what is intended. Maybe I misunderstand your point -
but the client address *is* returned? Admittedly its wrapped in a
BIO_ADDR, but its easy to get the underlying "raw" address using
BIO_ADDR_rawaddress():

https://www.openssl.org/docs/man1.1.0/crypto/BIO_ADDR_rawaddress.html

i.e. call BIO_ADDR_rawaddress() on the BIO_ADDR returned by
DTLSv1_listen() and then do something like this:

 /* Handle client connection */
 int client_fd = socket(AF_INET6, SOCK_DGRAM, 0);
 bind(client_fd, _addr, sizeof(struct sockaddr_in6));
 connect(client_fd, _addr, sizeof(struct sockaddr_in6));
 /* Set new fd and set BIO to connected */
 BIO *cbio = SSL_get_rbio(ssl);
 BIO_set_fd(cbio, client_fd, BIO_NOCLOSE);
 BIO_ctrl(cbio, BIO_CTRL_DGRAM_SET_CONNECTED, 0, _addr);
 /* Finish handshake */
 SSL_accept(ssl);

> 
> b) the existing FD might have additional packets from other clients. This
>argues for opening a new socket for the new client, and leaving the queue
>on the existing FD.

Which is what I recommend.


> I absolutely need to have recvmsg()/sendmsg() in the bss_dgram.c in order to
> get the destination address used.   This IPv6 code is portable, since the RFC
> API says how to do it.

Why isn't recvfrom() suitable (which is what the code currently uses to
get the address)?

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

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

[Michael Richardson]

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> DTLSv1_accept() is useable by programs that need to treat
mcr> DTLS interfaces in a way similar to TCP: new connections
mcr> must be accepted, and new sockets created.

mattcaswell> Your going to give more justification than this. Why is it
mattcaswell> that DTLSv1_listen() is not appropriate for your use case?

As I understand using DTLSv1_listen(), one does the following:
  1) open a UDP socket, bind(2) it appropriately.
 {in an RTP context, one might already know the remote port numbers, and
 one could connect(2) it already. In the CoAP case, that certainly is not
 the case}
 Put the socket into an SSL, do appropriate blocking or non-blocking
 event handling in application.

  2) call DTLSv1_listen() when there is traffic.
 DTLSv1_listen() will process (via peek) the first packet in the socket.
 If it's a Client Hello without a cookie, then a Hello Verify is sent
 back (%).  If it ate the packet, then it loops until it find something
 it can't handle or runs out of packets.

  3) DTLSv1_listen(), when it finds a Client Hello with a cookie, marks the
 provided SSL as having transitioned to a state where things can start,
 and it returns 1, along with the BIO_ADDR of the newly Verify Hello'ed 
client.

  4) the application is now expected to connect() the FD to the BIO_ADDR,
 and call SSL_accept(), and then to proceed with SSL_read()/SSL_write(), 
etc.

Perhaps I've gotten something wrong with this process.

This flow is entirely appropriate for a RTP user, but for a CoAP server there
are a number of problems:

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 which to 
receive
   new connections, or it can open a new socket on which to communicate with
   the new client.The second method is better for reason (b) below.
   Either way, it socket to communicate with the client needs to be bind(2)
   to the address that the client used to communicate with the server, and
   DTLSv1_listen() didn't collect or return that information.

b) the existing FD might have additional packets from other clients. This
   argues for opening a new socket for the new client, and leaving the queue
   on the existing FD.

c) the DTLSv1_listen() uses the SSL* (and associated CTX) that is provided to
   it for callbacks, and cookie verification.  It modifies the state of that
   SSL* to continue the transaction.
   I think that the roles should be split up.

also, from point (2) above:
(%) - the send that DTLSv1_listen() depends upon the socket having been
bind(2) with a non-INADDR_ANY/IN6ADDR_ANY_INIT IP address, or that the
system in question has only a single IP address.  This is because the
write that is done relies upon the kernel to pick the right source
address,  which appears to be easy for IPv4 with a single interface, but
trivially can fail for IPv6 even with a single interface due to
temporary, stable-private, and link-local addresses.


DTLSv1_accept() takes two SSL*.  The first is used for cookie verification,
while the second is filled in with a new FD that has been bind/connect to the
client and state advanced to be ready for SSL_accept().  It also returns the
same BIO_ADDR for the client, but that could be removed as it can trivially
be retrieved from the new SSL*.

mattcaswell> In any case the PR as it currently stands is a very long way
mattcaswell> off being acceptable:

I totally agree, but I had to post something to start the conversation.

mattcaswell> * As you point out the use of the POSIX socket APIs is
mattcaswell> unacceptable and is at the wrong level of abstraction. I
mattcaswell> might perhaps expect to see this sort of thing in the BIO
mattcaswell> layer.

a) I could move the socket creation code into BIO layer, a new BIO_ctrl method
   could be created to "duplicate" the BIO.  This would probably eliminate
   having to expose BIO_ADDR_sockaddr{,_size} from libcrypto->libssl.

b) creation of a new socket could be a new callback.

c) DTLSv1_accept() could return at:
   "now set up a socket based upon the original rbio's peer/addr"
   as all of the subsequent operations could be done by the application given
 BIO_dgram_get_peer(rbio, client) and BIO_dgram_get_addr(rbio, ouraddr)

d) a combination of (a) and (c), where the duplication code is provided by
   the BIO layer, but the application could do something different if it
   needed to.

My preference is for (d), because I think that it's common code and 

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

[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] PKCS12 safecontents bag type deviation from spec

[Sands, Daniel]

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:



ASN1_ADB(PKCS12_SAFEBAG) = {
ADB_ENTRY(NID_keyBag, ASN1_EXP(PKCS12_SAFEBAG, value.keybag,
PKCS8_PRIV_KEY_INFO, 0)),
ADB_ENTRY(NID_pkcs8ShroudedKeyBag, ASN1_EXP(PKCS12_SAFEBAG,
value.shkeybag, X509_SIG, 0)),
ADB_ENTRY(NID_safeContentsBag, ASN1_EXP_SET_OF(PKCS12_SAFEBAG,
value.safes, PKCS12_SAFEBAG, 0)),
ADB_ENTRY(NID_certBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag,
PKCS12_BAGS, 0)),
ADB_ENTRY(NID_crlBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag,
PKCS12_BAGS, 0)),
ADB_ENTRY(NID_secretBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag,
PKCS12_BAGS, 0))
} ASN1_ADB_END(PKCS12_SAFEBAG, 0, type, 0, _default_tt, NULL);




PKCS12 specifies that a safecontents bag is a SEQUENCE OF safecontents,
just like the top-level authsafe is:



SafeContents ::= SEQUENCE OF SafeBag

...

The sixth type of bag that can be held in a SafeBag is a
   SafeContents.




Is the deviation from the spec intentional?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] NonStop platform support

[Randall S. Becker]

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> officially support the HPE NonStop NSE/NSX platforms - but it
> rsbecker> is used on the platform through my team's port, which I
> rsbecker> currently support, and through other ports as well. Added a
> rsbecker> dependency to Apache is likely to dead-end the project for us
> rsbecker> depending on the depth of the dependency, if I understand
> rsbecker> where this is going (hoping I am wrong).
> 
> I pulled this away from the Speck discussion as it is indeed OT.
> 
> Does this involve some specific config target?  In that case, you might be
> interested in the effort in PR 5043:
> https://github.com/openssl/openssl/pull/5043
> 
> (if you claim the use of and can verify the correctness of some specific
config
> target(s), they can be classified as community
> supported)

I am authorized to claim that the ITUGLIB team (including myself) can
support this effort for the following config targets:
NONSTOP_KERNEL:[HJ]*:*:NSE* # H- or J-Series, IA64
NONSTOP_KERNEL:L*:*:NSX*) # x86-64

Our current port is current with 1.0.2n with platform mods. I have posted
such to the 5043 pull discussion and can create a pull request with our
modifications for review.

Regards,
Randall

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

[openssl-dev] OpenSSL wins the Levchin prize

[Matt Caswell]

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 list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Daniel Kahn Gillmor]

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 public domain for a number of years and 
> there are quite a few white papers and articles on the Ciphers. Allowing 
> public scrutiny and crypto-analysis is one way to put a cipher through 
> the grinder to make sure there are no back doors or weaknesses.

It sounds like we agree that adversarial cryptanalysis is a necessary
component of evaluating cryptographic algorithms today. :)

And yes, Simon and Speck have indeed been published for a while now.  My
understanding is that there has been a steady stream of cryptanalysis
against them, which has made some non-negligible progress in whittling
down their initially-claimed security levels.

Meanwhile (as i said above), the designers have not been particularly
forthcoming with producing their design goals and their own
cryptanalysis, despite requests for those documents.  Shouldn't the
designers of algorithms intended to be used by the public also be
transparent about their design goals and their own understanding of the
strengths and weaknesses of the algorithms they're proposing?  This
seems particularly relevant when the designers have been plausibly
accused of trying to pass off sub-standard cryptographic algorithms as
acceptable for public consumption (e.g. "we got punked" as one NIST
representative described the Dual EC DRBG fiasco).

I'd personally like to see documentation of the internal design goals
and cryptanalysis from the authors of Simon and Speck before considering
it for wider adoption, especially given that reasonably efficient strong
ciphers are already available.  Or do you think that knowing the
designers' goals and internal analysis should not a relevant criterion
for consideration?

Regards,

   --dkg


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Wim Lewis]

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 modernized 
> since early ports. Most of the differences are the addition of a FLOSS layer 
> (though #includes) and one byte swap issue on bn_mul_add_words that I'm not 
> sure is relevant anymore. Some of the tracked files that generated 
> (tests/Makefile) have spacing difference due to tooling differences. The 
> code, however, is very close to vanilla as of 1.0.2n.

In this case, I think Dmitry Belyavsky's suggestion makes the most sense. SPECK 
can be built as an ENGINE, the same way that GOST, CAPI, etc. are. (see [1].) 
This may require small changes to OpenSSL proper (to add OIDs, say), but they 
should be small enough not to add any complexity or maintenance burden to 
OpenSSL. If/when SPECK gains more use, or is considered for standardization in 
TLS, etc., then this codebase can be moved into OpenSSL's. In the meantime, 
people can build the SPECK engine to use it in an OpenSSL-based program.

[1] https://github.com/gost-engine/engine

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

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

[William Bathurst]

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

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 of which comes in a
variety of widths and key sizes and is targeted towards resource
constrained devices and environments. This implementation is
currently implemented using the 128 and 256 block sizes.

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:

1) Community interest in such a lightweight cipher.
2) Committers willing to help on the code for improvements.
3) Information on how to make this available as a patch.

We have currently integrated Speck with OpenSSL 1.1. We also have
an Speck Client software available for people who wish to test
this software. Future ports will be to mbedTLS.

We have listed making it available as an issue:

https://github.com/openssl/openssl/issues


OpenSSL/Speck Integration open source repositories:

https://github.com/m2mi/openssl_speck

https://github.com/m2mi/open_speck


Feel free to contact to to discuss the cipher and uses.

With Regards,
Bill

-- 
openssl-dev mailing list

To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-dev





--
SY, Dmitry Belyavsky




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

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

[William Bathurst]

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 quite a few white papers and articles on the Ciphers. Allowing 
public scrutiny and crypto-analysis is one way to put a cipher through 
the grinder to make sure there are no back doors or weaknesses.


Regards,
Bill


On 1/5/2018 11:33 AM, Daniel Kahn Gillmor wrote:

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)


SPECK is a lightweight block ciphers each of which comes in a variety of
widths and key sizes and is targeted towards resource constrained
devices and environments. This implementation is currently implemented
using the 128 and 256 block sizes.

Thanks for your work on this, and for reporting on it here.  Out of
curiosity, who is the "We" involved here?  The changeset history
appears to be a bit ambivalent about the authorship, based on edits to
the README itself:

   
https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
   
https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019


1) Community interest in such a lightweight cipher.

I'm not convinced that the OpenSSL project should encourage the adoption
of SPECK, given the general level of distrust around the algorithm:

   https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html

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.

Regards,

   --dkg


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

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

[Misaki Miyashita]

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 be able to submit a
PR against the master branch at this moment.

Thus, I was hoping to get a review on the suggested fix for the 1.0.2
to see it is viable by the upstream first.

Would it be possible to get a review on the openssl-dev@openssl.org
alias? or filing an issue via github is the right course of action?


You already got a review, from Viktor.


I totally missed the review from Viktor.  I'll follow up on the thread.
Sorry about that.


   I don't think there's much
reason to file an issue in github without a patch (and if there's a
patch, it should just go straight to a pull request with no separate
issue).  If you want the feature to get upstreamed, the onus is on you
to forward-port the patch to master and adapt it to review comments; I
don't think we've seen sufficient interest to cause a team member to
spontaneously take that work upon themselves.


Understood.  Thanks for your input.
Once we move to the 1.1 release train, we will look into the issue and 
submit a PR.


Thank you,

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

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

[Benjamin Kaduk via openssl-dev]

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 only allows bug fixes to be
>> backported to the stable branches, not new features. To me, this code
>> seems more like a new feature than a bugfix, though I do not claim to
>> speak authoritatively on the matter.
>>
>> The preferred mechanism for submitting patches is as github pull
>> requests (against the master branch, with a note in the pull request
>> message if the backport is desired).
>
> 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 be able to submit a
> PR against the master branch at this moment.
>
> Thus, I was hoping to get a review on the suggested fix for the 1.0.2
> to see it is viable by the upstream first.
>
> Would it be possible to get a review on the openssl-dev@openssl.org
> alias? or filing an issue via github is the right course of action?
>

You already got a review, from Viktor.  I don't think there's much
reason to file an issue in github without a patch (and if there's a
patch, it should just go straight to a pull request with no separate
issue).  If you want the feature to get upstreamed, the onus is on you
to forward-port the patch to master and adapt it to review comments; I
don't think we've seen sufficient interest to cause a team member to
spontaneously take that work upon themselves.

-Ben

> Thanks again for your comment.
>
> Regards,
>
> -- misaki

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

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

[Misaki Miyashita]

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, not new features. To me, this code
seems more like a new feature than a bugfix, though I do not claim to
speak authoritatively on the matter.

The preferred mechanism for submitting patches is as github pull
requests (against the master branch, with a note in the pull request
message if the backport is desired).


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 be able to submit a 
PR against the master branch at this moment.


Thus, I was hoping to get a review on the suggested fix for the 1.0.2 to 
see it is viable by the upstream first.


Would it be possible to get a review on the openssl-dev@openssl.org 
alias? or filing an issue via github is the right course of action?


Thanks again for your comment.

Regards,

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

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

[Hubert Kario]

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:
> 
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-20
> 15/documents/papers/session1-shors-paper.pdf
> 
> 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 a device CPU may only have 32K of
> RAM. Therefore security is an afterthought by developers. For some only
> AES 128 is available and they wish to use 256 bit encryption. Then Speck
> 256 would be an option because it has better performance and provides
> sufficient security.

so security is afterthought, but they got out of their way to use "more 
secure" (debatable) option?

sorry, that does not hold water
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] NonStop platform support

[Randall S. Becker]

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 but do use OpenSSL. I understand that OpenSSL does not
> rsbecker> officially support the HPE NonStop NSE/NSX platforms - but it
> rsbecker> is used on the platform through my team's port, which I
> rsbecker> currently support, and through other ports as well. Added a
> rsbecker> dependency to Apache is likely to dead-end the project for us
> rsbecker> depending on the depth of the dependency, if I understand
> rsbecker> where this is going (hoping I am wrong).
> 
> I pulled this away from the Speck discussion as it is indeed OT.
> 
> Does this involve some specific config target?  In that case, you might be
> interested in the effort in PR 5043:
> https://github.com/openssl/openssl/pull/5043
> 
> (if you claim the use of and can verify the correctness of some specific
config
> target(s), they can be classified as community
> supported)

I'm going to bring this to my team, but expect a good outcome. The platforms
we are supporting are (from config):
NONSTOP_KERNEL:[HJ]*:*:NSE*) # H- or J-Series, IA64
NONSTOP_KERNEL:L*:*:NSX*) # x86-64

Cheers,
Randall

-- Brief whoami: NonStop developer since approximately
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.



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

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

[Randall S. Becker]

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 #includes) and one byte swap issue on bn_mul_add_words that I'm not 
sure is relevant anymore. Some of the tracked files that generated 
(tests/Makefile) have spacing difference due to tooling differences. The code, 
however, is very close to vanilla as of 1.0.2n.

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

[openssl-dev] NonStop platform support

[Richard Levitte]

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 not officially support the HPE NonStop NSE/NSX
rsbecker> platforms - but it is used on the platform through my team's
rsbecker> port, which I currently support, and through other ports as
rsbecker> well. Added a dependency to Apache is likely to dead-end the
rsbecker> project for us depending on the depth of the dependency, if
rsbecker> I understand where this is going (hoping I am wrong).

I pulled this away from the Speck discussion as it is indeed OT.

Does this involve some specific config target?  In that case, you
might be interested in the effort in PR 5043:
https://github.com/openssl/openssl/pull/5043

(if you claim the use of and can verify the correctness of some
specific config target(s), they can be classified as community
supported)

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

[Randall S. Becker]

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
> >> 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 license.  The future direction of OpenSSL
> >> is moving to Apache, anda it’s unlikely this work would show up in
> >> OpenSSL before we change the license.
> >>
> >> We’ll soon have a blog post about our current thoughts on a crypto policy.
> >> Watch this space.
> >>
> >> For discussion, the future-compatible thing to do :) is open a GitHub 
> >> issue.
> >> Then, make a pull request after the issue discussion seems to have
> >> died down.
> > A request, maybe OT. The NonStop platform does broadly deploy Apache
> but do use OpenSSL. I understand that OpenSSL does not officially support
> the HPE NonStop NSE/NSX platforms - but it is used on the platform through
> my team's port, which I currently support, and through other ports as well.
> Added a dependency to Apache is likely to dead-end the project for us
> depending on the depth of the dependency, if I understand where this is
> going (hoping I am wrong).
> >
> 
> Apache license, not Apache software.

Thank you thank you thank you , but sorry about adding noise to the 
conversation.
Cheers,
Randall

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

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

[Benjamin Kaduk via openssl-dev]

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 Apache license. We would love
>> input on the following items:
>>
>> Don’t bother changing the license.  The future direction of OpenSSL is moving
>> to Apache, anda it’s unlikely this work would show up in OpenSSL before we
>> change the license.
>>
>> We’ll soon have a blog post about our current thoughts on a crypto policy.
>> Watch this space.
>>
>> For discussion, the future-compatible thing to do :) is open a GitHub issue.
>> Then, make a pull request after the issue discussion seems to have died
>> down.
> A request, maybe OT. The NonStop platform does broadly deploy Apache but do 
> use OpenSSL. I understand that OpenSSL does not officially support the HPE 
> NonStop NSE/NSX platforms - but it is used on the platform through my team's 
> port, which I currently support, and through other ports as well. Added a 
> dependency to Apache is likely to dead-end the project for us depending on 
> the depth of the dependency, if I understand where this is going (hoping I am 
> wrong).
>

Apache license, not Apache software.   

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

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

[Randall S. Becker]

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 following items:
> 
> Don’t bother changing the license.  The future direction of OpenSSL is moving
> to Apache, anda it’s unlikely this work would show up in OpenSSL before we
> change the license.
> 
> We’ll soon have a blog post about our current thoughts on a crypto policy.
> Watch this space.
> 
> For discussion, the future-compatible thing to do :) is open a GitHub issue.
> Then, make a pull request after the issue discussion seems to have died
> down.

A request, maybe OT. The NonStop platform does broadly deploy Apache but do use 
OpenSSL. I understand that OpenSSL does not officially support the HPE NonStop 
NSE/NSX platforms - but it is used on the platform through my team's port, 
which I currently support, and through other ports as well. Added a dependency 
to Apache is likely to dead-end the project for us depending on the depth of 
the dependency, if I understand where this is going (hoping I am wrong).

With respect,
Randall

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

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

[Benjamin Kaduk via openssl-dev]

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 is linking to a bad/expired certificate.  This may not be
>> the most elegant solution, but it is a minimal change with low impact
>> to the rest of the code.
>>
>> Could I possibly get a review on the change? and possibly be
>> considered to be integrated to the upstream?
>> (This is for the 1.0.1 branch)
>
> 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, not new features. To me, this code
seems more like a new feature than a bugfix, though I do not claim to
speak authoritatively on the matter.

The preferred mechanism for submitting patches is as github pull
requests (against the master branch, with a note in the pull request
message if the backport is desired).

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

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

[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 license.  The future direction of OpenSSL is moving 
to Apache, anda it’s unlikely this work would show up in OpenSSL before we 
change the license.

We’ll soon have a blog post about our current thoughts on a crypto policy.  
Watch this space.

For discussion, the future-compatible thing to do :) is open a GitHub issue.  
Then, make a pull request after the issue discussion seems to have died down.

Hope this helps.

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

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

[Hanno Böck]

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 a device CPU may only have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.

Why would someone want a 256 bit cipher in a constrained device? This
sounds more like crypto numerology to me where people think "larger
keys are better just because". I'd take a well researched algorithm
like aes128 over a hardly researcherd 256 bit one every time.

> Based on the above scenario you can likely see why we are interested
> in OpenSSL. First, OpenSSL can be used for terminating lightweight
> TLS connections near the edge, and then forwarding using commonly
> used ciphers.

Ok, so we're talking about Speck in TLS here.
I feel this raises the bar even more and doesn't really belong here any
time soon.
Is there any effort in standardizing this? I haven't seen it on the TLS
WG mailing list and I tried to google speck tls draft and haven't found
anything.

For the record: I feel such a move - adding a new cipher to TLS -
requires much more than "we want a lightweight cipher and NSA gave us
one".
If there is serious demand for more lightweight ciphers in TLS I'd
expect some kind of open and transparent competition like it happened
with AES or SHA3 - or at least some open discussion in CFRG. However I'm
not convinced this demand even exists.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dmitry Belyavsky]

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,
>
> 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) <
> https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>
> SPECK is a lightweight block ciphers each of which comes in a variety of
> widths and key sizes and is targeted towards resource constrained devices
> and environments. This implementation is currently implemented using the
> 128 and 256 block sizes.
>
> 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:
>
> 1) Community interest in such a lightweight cipher.
> 2) Committers willing to help on the code for improvements.
> 3) Information on how to make this available as a patch.
>
> We have currently integrated Speck with OpenSSL 1.1. We also have an Speck
> Client software available for people who wish to test this software. Future
> ports will be to mbedTLS.
>
> We have listed making it available as an issue:
>
> https://github.com/openssl/openssl/issues
>
> OpenSSL/Speck Integration open source repositories:
>
> https://github.com/m2mi/openssl_speck
> https://github.com/m2mi/open_speck
>
> Feel free to contact to to discuss the cipher and uses.
>
> With Regards,
> Bill
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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 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 devices?
> 
> Note: I'm not terribly partial either way, just thought that we need
> to look at it from a broader perspective...
> 
> Cheers,
> Richard
> 
> In message  on Mon, 8 Jan 2018 
> 13:58:59 -0800 (PST), Paul Dale  said:
> 
> paul.dale> 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 be the smallest, fastest and most feature laden :)  To sell 
> to the US government,  your first selection criteria should be "does the 
> toolkit have a current FIPS validation?"  From memory this means: ECT, 
> nanoSSL or WolfSSL.
> paul.dale> 
> paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less 
> suitable for embedded applications, especially tightly resource constrained 
> ones.  It is possible to cut OpenSSL down in size but it will never compete 
> with the designed for embedded toolkits.  Plus, the FIPS module is fixed and 
> cannot be shrunk.
> paul.dale> 
> paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds 
> currently.  FIPS is on the project plan for 1.1 but it isn't available at the 
> moment.  The US government is forbidden to purchase any product that contains 
> cryptographic operations unless the product has a FIPS validation.  No FIPS, 
> no sale.
> paul.dale> 
> paul.dale> 
> paul.dale> Pauli
> paul.dale> -- 
> paul.dale> Oracle
> paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> paul.dale> Phone +61 7 3031 7217
> paul.dale> Oracle Australia
> paul.dale> 
> paul.dale> -Original Message-
> paul.dale> From: William Bathurst [mailto:wbath...@gmail.com] 
> paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
> paul.dale> To: openssl-dev@openssl.org
> paul.dale> Cc: llamour...@gmail.com
> paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL
> paul.dale> 
> paul.dale> Hi Hanno/all,
> paul.dale> 
> paul.dale> 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:
> paul.dale> 
> paul.dale> 
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
> paul.dale> 
> paul.dale> 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 a device CPU may only have 32K of RAM. 
> Therefore security is an afterthought by developers. For some only AES 128 is 
> available and they wish to use 256 bit encryption. Then Speck
> paul.dale> 256 would be an option because it has better performance and 
> provides sufficient security.
> paul.dale> 
> paul.dale> Based on the above scenario you can likely see why we are 
> interested in OpenSSL. First, OpenSSL can be used for terminating lightweight 
> TLS connections near the edge, and then forwarding using commonly used 
> ciphers.
> paul.dale> 
> paul.dale> [IoT Device] -TLS/Speck>[IoT Gateway]-TLS> 
> [Services]
> paul.dale> 
> paul.dale> Also, we are interested in using OpenSSL libraries at the edge for 
> client creation. One thing we would like to do is provide instructions for an 
> highly optimized build of OpenSSL that can be used for contrained devices.
> paul.dale> 
> paul.dale> I think demand will eventually grow because there is an initiative 
> by the US government to improve IoT Security and Speck is being developed and 
> proposed as a standard within the government. Therefore, I see users who wish 
> to play in this space would be interested in a version where Speck could be 
> used in OpenSSL.
> paul.dale> 
> paul.dale> It is my hope to accomplish the following:
> paul.dale> 
> paul.dale> [1] Make Speck available via Open Source, this could be as an 
> option or as a patch in OpenSSL.
> paul.dale> [2] If we make it available as a patch, is there a place where we 
> would announce/make it known that it is available?
> paul.dale> 
> paul.dale> We are also looking at open-sourcing the client side code. This 
> would be used to create light-weight clients that use Speck and currently we 
> 

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

[Misaki Miyashita]

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 
most elegant solution, but it is a minimal change with low impact to 
the rest of the code.


Could I possibly get a review on the change? and possibly be 
considered to be integrated to the upstream?

(This is for the 1.0.1 branch)


Sorry, I meant to say it is for the 1.0.2 branch.



Thanks in advance.

-- misaki


--- a/crypto/x509/x509_vfy.c2017-11-02 07:32:58.0 -0700
+++ b/crypto/x509/x509_vfy.c2017-12-11 12:37:55.591835780 -0800
@@ -185,6 +185,39 @@
 return xtmp;
 }

+/*
+ * Look through the trust store setup by get_issuer() and
+ * return the certificate which matches the server cert 'x'
+ * via 'xtmp'.
+ */
+static int X509_get_cert(X509 **xtmp, X509_STORE_CTX *ctx, X509 *x)
+{
+X509_OBJECT*tmp;
+inti;
+intret = 0;
+
+CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
+for (i = 0; i < sk_X509_OBJECT_num(ctx->ctx->objs); i++) {
+tmp = sk_X509_OBJECT_value(ctx->ctx->objs, i);
+if (tmp == NULL) {
+goto exit;
+}
+if (X509_cmp(tmp->data.x509, x) == 0) {
+/*
+ * Found the cert in the trust store which matches the
+ * server cert.  Increment the ref count and return.
+ */
+X509_OBJECT_up_ref_count(tmp);
+*xtmp = tmp->data.x509;
+ret = 1;
+goto exit;
+}
+}
+exit:
+CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
+return ret;
+}
+
 int X509_verify_cert(X509_STORE_CTX *ctx)
 {
 X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
@@ -316,9 +350,13 @@
  * We have a single self signed certificate: see if 
we can
  * find it in the store. We must have an exact match 
to avoid

  * possible impersonation.
+ * get_issuer() sets up the trust store for the 
subject and
+ * returns the first cert via 'xtmp'. The first cert 
in the
+ * trust store may not be the certificate that we are 
interested
+ * in. Look through the trust store to see there is 
an exact match.

  */
 ok = ctx->get_issuer(, ctx, x);
-if ((ok <= 0) || X509_cmp(x, xtmp)) {
+if ((ok <= 0) || (X509_get_cert(, ctx, x) != 1)) {
 ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
 ctx->current_cert = x;
 ctx->error_depth = i - 1;


On 10/21/17 03:21 PM, Viktor Dukhovni wrote:


On Oct 21, 2017, at 11:20 AM, Misaki Miyashita 
 wrote:


We encountered a problem using OpenLDAP with OpenSSL when there were 
more than one certificate with the same subject.


Does OpenSSL stop searching for a valid certificate when it finds a 
certificate with matching DN?

Yes, when a matching issuer is found in the trust store, but is expired
no alternative certificates will be tested.  You need to remove outdated
issuer certificates from your trust store before they expire.





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

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

[Richard Levitte]

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

Note: I'm not terribly partial either way, just thought that we need
to look at it from a broader perspective...

Cheers,
Richard

In message  on Mon, 8 Jan 2018 
13:58:59 -0800 (PST), Paul Dale  said:

paul.dale> 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 be 
the smallest, fastest and most feature laden :)  To sell to the US government,  
your first selection criteria should be "does the toolkit have a current FIPS 
validation?"  From memory this means: ECT, nanoSSL or WolfSSL.
paul.dale> 
paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less 
suitable for embedded applications, especially tightly resource constrained 
ones.  It is possible to cut OpenSSL down in size but it will never compete 
with the designed for embedded toolkits.  Plus, the FIPS module is fixed and 
cannot be shrunk.
paul.dale> 
paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds 
currently.  FIPS is on the project plan for 1.1 but it isn't available at the 
moment.  The US government is forbidden to purchase any product that contains 
cryptographic operations unless the product has a FIPS validation.  No FIPS, no 
sale.
paul.dale> 
paul.dale> 
paul.dale> Pauli
paul.dale> -- 
paul.dale> Oracle
paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption 
paul.dale> Phone +61 7 3031 7217
paul.dale> Oracle Australia
paul.dale> 
paul.dale> -Original Message-
paul.dale> From: William Bathurst [mailto:wbath...@gmail.com] 
paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
paul.dale> To: openssl-dev@openssl.org
paul.dale> Cc: llamour...@gmail.com
paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL
paul.dale> 
paul.dale> Hi Hanno/all,
paul.dale> 
paul.dale> 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:
paul.dale> 
paul.dale> 
https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
paul.dale> 
paul.dale> 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 a device CPU may only have 32K of RAM. 
Therefore security is an afterthought by developers. For some only AES 128 is 
available and they wish to use 256 bit encryption. Then Speck
paul.dale> 256 would be an option because it has better performance and 
provides sufficient security.
paul.dale> 
paul.dale> Based on the above scenario you can likely see why we are interested 
in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS 
connections near the edge, and then forwarding using commonly used ciphers.
paul.dale> 
paul.dale> [IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]
paul.dale> 
paul.dale> Also, we are interested in using OpenSSL libraries at the edge for 
client creation. One thing we would like to do is provide instructions for an 
highly optimized build of OpenSSL that can be used for contrained devices.
paul.dale> 
paul.dale> I think demand will eventually grow because there is an initiative 
by the US government to improve IoT Security and Speck is being developed and 
proposed as a standard within the government. Therefore, I see users who wish 
to play in this space would be interested in a version where Speck could be 
used in OpenSSL.
paul.dale> 
paul.dale> It is my hope to accomplish the following:
paul.dale> 
paul.dale> [1] Make Speck available via Open Source, this could be as an option 
or as a patch in OpenSSL.
paul.dale> [2] If we make it available as a patch, is there a place where we 
would announce/make it known that it is available?
paul.dale> 
paul.dale> We are also looking at open-sourcing the client side code. This 
would be used to create light-weight clients that use Speck and currently we 
also build basic OAuth capability on top of it.
paul.dale> 
paul.dale> Thanks for your input!
paul.dale> 
paul.dale> Bill
paul.dale> 
paul.dale> On 1/5/2018 11:40 AM, Hanno Böck wrote:
paul.dale> > On Fri, 5 Jan 2018 10:52:01 -0800
paul.dale> > William Bathurst  wrote:
paul.dale> >
paul.dale> >> 1) Community interest in such a lightweight cipher.
paul.dale> > I think there's a shifting view that "more is not always good" in 
paul.dale> 

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

[Paul Dale]

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 be the 
smallest, fastest and most feature laden :)  To sell to the US government,  
your first selection criteria should be "does the toolkit have a current FIPS 
validation?"  From memory this means: ECT, nanoSSL or WolfSSL.

The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less suitable for 
embedded applications, especially tightly resource constrained ones.  It is 
possible to cut OpenSSL down in size but it will never compete with the 
designed for embedded toolkits.  Plus, the FIPS module is fixed and cannot be 
shrunk.

The current OpenSSL FIPS validation only applies to 1.0.2 builds currently.  
FIPS is on the project plan for 1.1 but it isn't available at the moment.  The 
US government is forbidden to purchase any product that contains cryptographic 
operations unless the product has a FIPS validation.  No FIPS, no sale.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-Original Message-
From: William Bathurst [mailto:wbath...@gmail.com] 
Sent: Tuesday, 9 January 2018 7:10 AM
To: openssl-dev@openssl.org
Cc: llamour...@gmail.com
Subject: 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 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 a device CPU may only have 32K of RAM. Therefore 
security is an afterthought by developers. For some only AES 128 is available 
and they wish to use 256 bit encryption. Then Speck
256 would be an option because it has better performance and provides 
sufficient security.

Based on the above scenario you can likely see why we are interested in 
OpenSSL. First, OpenSSL can be used for terminating lightweight TLS connections 
near the edge, and then forwarding using commonly used ciphers.

[IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]

Also, we are interested in using OpenSSL libraries at the edge for client 
creation. One thing we would like to do is provide instructions for an highly 
optimized build of OpenSSL that can be used for contrained devices.

I think demand will eventually grow because there is an initiative by the US 
government to improve IoT Security and Speck is being developed and proposed as 
a standard within the government. Therefore, I see users who wish to play in 
this space would be interested in a version where Speck could be used in 
OpenSSL.

It is my hope to accomplish the following:

[1] Make Speck available via Open Source, this could be as an option or as a 
patch in OpenSSL.
[2] If we make it available as a patch, is there a place where we would 
announce/make it known that it is available?

We are also looking at open-sourcing the client side code. This would be used 
to create light-weight clients that use Speck and currently we also build basic 
OAuth capability on top of it.

Thanks for your input!

Bill

On 1/5/2018 11:40 AM, Hanno Böck wrote:
> 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.
>
> Therefore I'd generally oppose adding ciphers without a clear usecase, 
> as increased code complexity has a cost.
> So I think questions that should be answered:
> What's the usecase for speck in OpenSSL? Are there plans to use it in 
> TLS? If yes why? By whom? What advantages does it have over existing 
> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>
>
> Also just for completeness, as some may not be aware: There are some 
> concerns about Speck due to its origin (aka the NSA). I don't think 
> that is a reason to dismiss a cipher right away, what I'd find more 
> concerning is that from what I observed there hasn't been a lot of 
> research about speck.
>

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

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

[Misaki Miyashita]

(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 change with low impact to the rest 
of the code.


Could I possibly get a review on the change? and possibly be considered 
to be integrated to the upstream?

(This is for the 1.0.1 branch)

Thanks in advance.

-- misaki


--- a/crypto/x509/x509_vfy.c2017-11-02 07:32:58.0 -0700
+++ b/crypto/x509/x509_vfy.c2017-12-11 12:37:55.591835780 -0800
@@ -185,6 +185,39 @@
 return xtmp;
 }

+/*
+ * Look through the trust store setup by get_issuer() and
+ * return the certificate which matches the server cert 'x'
+ * via 'xtmp'.
+ */
+static int X509_get_cert(X509 **xtmp, X509_STORE_CTX *ctx, X509 *x)
+{
+X509_OBJECT*tmp;
+inti;
+intret = 0;
+
+CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
+for (i = 0; i < sk_X509_OBJECT_num(ctx->ctx->objs); i++) {
+tmp = sk_X509_OBJECT_value(ctx->ctx->objs, i);
+if (tmp == NULL) {
+goto exit;
+}
+if (X509_cmp(tmp->data.x509, x) == 0) {
+/*
+ * Found the cert in the trust store which matches the
+ * server cert.  Increment the ref count and return.
+ */
+X509_OBJECT_up_ref_count(tmp);
+*xtmp = tmp->data.x509;
+ret = 1;
+goto exit;
+}
+}
+exit:
+CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
+return ret;
+}
+
 int X509_verify_cert(X509_STORE_CTX *ctx)
 {
 X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
@@ -316,9 +350,13 @@
  * We have a single self signed certificate: see if we can
  * find it in the store. We must have an exact match 
to avoid

  * possible impersonation.
+ * get_issuer() sets up the trust store for the subject and
+ * returns the first cert via 'xtmp'. The first cert in the
+ * trust store may not be the certificate that we are 
interested
+ * in. Look through the trust store to see there is an 
exact match.

  */
 ok = ctx->get_issuer(, ctx, x);
-if ((ok <= 0) || X509_cmp(x, xtmp)) {
+if ((ok <= 0) || (X509_get_cert(, ctx, x) != 1)) {
 ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
 ctx->current_cert = x;
 ctx->error_depth = i - 1;


On 10/21/17 03:21 PM, Viktor Dukhovni wrote:


On Oct 21, 2017, at 11:20 AM, Misaki Miyashita  
wrote:


We encountered a problem using OpenLDAP with OpenSSL when there were more than 
one certificate with the same subject.

Does OpenSSL stop searching for a valid certificate when it finds a certificate 
with matching DN?

Yes, when a matching issuer is found in the trust store, but is expired
no alternative certificates will be tested.  You need to remove outdated
issuer certificates from your trust store before they expire.



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

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

[Benjamin Kaduk via openssl-dev]

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:
>
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
>
>
> 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 a device CPU may only have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.
>
> Based on the above scenario you can likely see why we are interested
> in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS
> connections near the edge, and then forwarding using commonly used
> ciphers.
>
> [IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]
>
> Also, we are interested in using OpenSSL libraries at the edge for
> client creation. One thing we would like to do is provide instructions
> for an highly optimized build of OpenSSL that can be used for
> contrained devices.
>
> I think demand will eventually grow because there is an initiative by
> the US government to improve IoT Security and Speck is being developed
> and proposed as a standard within the government. Therefore, I see
> users who wish to play in this space would be interested in a version
> where Speck could be used in OpenSSL.
>
> It is my hope to accomplish the following:
>
> [1] Make Speck available via Open Source, this could be as an option
> or as a patch in OpenSSL.
> [2] If we make it available as a patch, is there a place where we
> would announce/make it known that it is available?
>
> We are also looking at open-sourcing the client side code. This would
> be used to create light-weight clients that use Speck and currently we
> also build basic OAuth capability on top of it.
>

Interestingly, the IETF ACE (Authentication and Authorization in
Constrained Environments) is chartered to look at this space (crypto for
constrained systems/IoT), and is aiming towards something roughly
OAuth-shaped, but there has not really been any interest in Speck
expressed that I've seen.  So, is this work happening someplace else, or
is there not actually demand for it?

-Ben

> Thanks for your input!
>
> Bill
>
> On 1/5/2018 11:40 AM, Hanno Böck wrote:
>> 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.
>>
>> Therefore I'd generally oppose adding ciphers without a clear usecase,
>> as increased code complexity has a cost.
>> So I think questions that should be answered:
>> What's the usecase for speck in OpenSSL? Are there plans to use it in
>> TLS? If yes why? By whom? What advantages does it have over existing
>> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>>
>>
>> Also just for completeness, as some may not be aware: There are some
>> concerns about Speck due to its origin (aka the NSA). I don't think
>> that is a reason to dismiss a cipher right away, what I'd find more
>> concerning is that from what I observed there hasn't been a lot of
>> research about speck.
>>
>

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

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

[William Bathurst]

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 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 a device CPU may only have 32K of 
RAM. Therefore security is an afterthought by developers. For some only 
AES 128 is available and they wish to use 256 bit encryption. Then Speck 
256 would be an option because it has better performance and provides 
sufficient security.


Based on the above scenario you can likely see why we are interested in 
OpenSSL. First, OpenSSL can be used for terminating lightweight TLS 
connections near the edge, and then forwarding using commonly used ciphers.


[IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]

Also, we are interested in using OpenSSL libraries at the edge for 
client creation. One thing we would like to do is provide instructions 
for an highly optimized build of OpenSSL that can be used for contrained 
devices.


I think demand will eventually grow because there is an initiative by 
the US government to improve IoT Security and Speck is being developed 
and proposed as a standard within the government. Therefore, I see users 
who wish to play in this space would be interested in a version where 
Speck could be used in OpenSSL.


It is my hope to accomplish the following:

[1] Make Speck available via Open Source, this could be as an option or 
as a patch in OpenSSL.
[2] If we make it available as a patch, is there a place where we would 
announce/make it known that it is available?


We are also looking at open-sourcing the client side code. This would be 
used to create light-weight clients that use Speck and currently we also 
build basic OAuth capability on top of it.


Thanks for your input!

Bill

On 1/5/2018 11:40 AM, Hanno Böck wrote:

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.

Therefore I'd generally oppose adding ciphers without a clear usecase,
as increased code complexity has a cost.
So I think questions that should be answered:
What's the usecase for speck in OpenSSL? Are there plans to use it in
TLS? If yes why? By whom? What advantages does it have over existing
ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)


Also just for completeness, as some may not be aware: There are some
concerns about Speck due to its origin (aka the NSA). I don't think
that is a reason to dismiss a cipher right away, what I'd find more
concerning is that from what I observed there hasn't been a lot of
research about speck.



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

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

[Daniel Kahn Gillmor]

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) 
> 
>
> SPECK is a lightweight block ciphers each of which comes in a variety of 
> widths and key sizes and is targeted towards resource constrained 
> devices and environments. This implementation is currently implemented 
> using the 128 and 256 block sizes.

Thanks for your work on this, and for reporting on it here.  Out of
curiosity, who is the "We" involved here?  The changeset history
appears to be a bit ambivalent about the authorship, based on edits to
the README itself:

  
https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
  
https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019

> 1) Community interest in such a lightweight cipher.

I'm not convinced that the OpenSSL project should encourage the adoption
of SPECK, given the general level of distrust around the algorithm:

  https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html

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.

Regards,

  --dkg


signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Hanno Böck]

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.

Therefore I'd generally oppose adding ciphers without a clear usecase,
as increased code complexity has a cost.
So I think questions that should be answered:
What's the usecase for speck in OpenSSL? Are there plans to use it in
TLS? If yes why? By whom? What advantages does it have over existing
ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)


Also just for completeness, as some may not be aware: There are some
concerns about Speck due to its origin (aka the NSA). I don't think
that is a reason to dismiss a cipher right away, what I'd find more
concerning is that from what I observed there hasn't been a lot of
research about speck.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] DTLS "accept" functionality

[Michael Richardson]

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 expected. If used
in CoAP situation, there are a number of race conditions that make it
hard to use correctly.   I wrote another email about that, which I think did
not get to the list, which I can resend.

I have preserved DLTSv1_listen() functionality, refactoring most of it
into DTLSv1_anwerHello(), and then adding DTLSv1_accept() on top of it.

Unfortunately I was also forced to delve into dgram_bss.c in order to bring
some additional information out; stuff which is rather OS dependant for IPv4,
and which perhaps would be better done in the application somehow.

I'm looking for advice.

Also, I found it difficult to find the right incantation to get a static
build; I noticed finally that my test/* programs were linking against the
libssl that was in my /lib, rather than the code I was testing.  I suggest
that this be captured into a ./Configure option.  I used:

 ./Configure no-shared --debug linux-x86_64

"no-dso" seemed like it ought to help, but it made things worse...

I hope that I added the new exposed symbols correctly.
I have yet to validate the complete david/coap/ruby-openssl/dtls
functionality, but I wanted to post this sooner for review.


https://github.com/openssl/openssl/pull/5024 says:

This patch refactors the DTLSv1_listen() to create an alternative API that is
called DTLSv1_accept().

DTLSv1_accept() is useable by programs that need to treat DTLS interfaces in
a way similar to TCP: new connections must be accepted, and new sockets
created.

There are a number of changes included here:

1. dgram_write() and dgram_read() now use sendmsg(2) and recvmsg(2) in order to 
set and collect the local address used in the datagram.  This allows a socket 
to bound to ::, while still sending traffic correctly from the address that the 
other peer used. The IPv6 version of this code is according to rfc3542 API, but 
the IPv4 of the code is Linux specific and needs to be either abstracted and 
translated for *BSD and Windows, or IPv6 mapped IPv4 sockets could be used.
2. a new BIO control SET_ADDR and GET_ADDR are added, and if the address is not 
set then it pulls it out of the socket using getsockname(2).
3. DTLSv1_accept() accepts a second SSL* on which new connections are setup. A 
new socket is set up using the addresses from the received message and it is 
inserted into the BIO. There is a race condition during setup which turned out 
to be unavoidable: between the bind(2) and the connect(2), the new socket could 
have the same address as the "listen" socket, and additional hello packets 
could arrive on the wrong socket.  Such packets will hopefully be dropped as 
garbage. It was thought that connect(2) could be called before bind(2), but 
that seems to cause the kernel to allocate a local address for the new socket 
(a random port), which the subsequent bind(2) can not seem to change.
4. the use of POSIX socket APIs inside this code is likely inappropriate and 
this routine should be split up in some better way so that socket activities 
can be done by the application, using the correct abstractions for the OS.
5. a new test case dtlsaccepttest was created.  It uses fork() and also calls 
system() on "openssl s_client". Probably it should just call code internally, 
but apps/* is not in a library form that can be used. Perhaps this use is 
acceptable.  Other test functions just use canned packets in/out, but since 
this is testing the creation/adaption of socket code, real sockets would seem 
to be necessary.  Probably this test case should be disabled on non-Unix 
platforms.
6. routines BIO_ADDR_sockaddr and BIO_ADDR_sockaddr_size exposed from libcrypto 
to libssl.  There might be a better way to do this, perhaps a BIO_CTRL would be 
better?



--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Speck Cipher Integration with OpenSSL

[William Bathurst]

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 of which comes in a variety of 
widths and key sizes and is targeted towards resource constrained 
devices and environments. This implementation is currently implemented 
using the 128 and 256 block sizes.


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:


1) Community interest in such a lightweight cipher.
2) Committers willing to help on the code for improvements.
3) Information on how to make this available as a patch.

We have currently integrated Speck with OpenSSL 1.1. We also have an 
Speck Client software available for people who wish to test this 
software. Future ports will be to mbedTLS.


We have listed making it available as an issue:

https://github.com/openssl/openssl/issues

OpenSSL/Speck Integration open source repositories:

https://github.com/m2mi/openssl_speck
https://github.com/m2mi/open_speck

Feel free to contact to to discuss the cipher and uses.

With Regards,
Bill

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

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

[murugesh pitchaiah]

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
openssl-fips-ecp-2.0.16 in canister model.

Please share if this is known issue and any fix available for the same.

Thanks,
Murugesh P.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Michael Richardson]

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 [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] weird loop in s3_lib.c

[Michael Richardson]

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)
continue;
}


The if (!ok) continue;
is just a no-op.  Maybe it said at some point:
  "if(ok) break;"

which would have an affect, or maybe there was some code after it that was
removed.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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 what action occurs when the
pointer is null. Also generally speaking is it supported to call openssl
free functions with null pointers?


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


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