Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Richard Levitte 
In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > H...  case 4 shouldn't pose too much problems unless you restart
kurt> > the application more than once every second or so (for a 1 second
kurt> > resolution).  On VMS, the system time is kept with 100 nanosecond
kurt> > granularity...  this doesn't mean that it's actually updated every 100
kurt> > nanosecond, but the possibility is there when VMS runs on fast enough
kurt> > hardware (a VAX is decidedly not in that range, Alpha has a minimum
kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  Either
kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
kurt> > counter to match the 128 bit nonce requirement, do I get that right?
kurt> 
kurt> The requirement is not to have it 128 bit. Just that it doesn't
kurt> repeat as often as a 128 random number. You're most likely not
kurt> going to instantiate it 2^64 times. As long as the combination is
kurt> unique, it should be fine.

"The requirements" depend on where you look.  Looking at the code, or
more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
this:

drbg->min_noncelen = drbg->min_entropylen / 2;

So the DRBG CTR code currently requires 128 bits minimum by default,
unconditionally.

Cheers,
Richard

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

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Richard Levitte 
In message <20180407185034.ga25...@roeckx.be> on Sat, 7 Apr 2018 20:50:35 
+0200, Kurt Roeckx  said:

kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
kurt> > work is just plain wrong.
kurt> 
kurt> So then I suggest we support the syscalls on all platforms that
kurt> provide it.

I'm sorry, I'm lost.  "the syscalls"?  You started refering to
syscalls when discussing getrandom(), so I'm going to assume that it's
related, but I fail to understand how it's related to platforms that
break, and most specifically to VMS.  What "syscalls" do you expect?

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

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Kurt Roeckx 
On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> > Because
> > - It is not clear we need to do so
> 
> >That we need to do what?
> 
> Do FIPS compliant random numbers in this release.

We will never have that in any release by default, like I already
stated a few times.

> Everything is a trade-off.  Please explain why you want AES256-CTR with a 
> nonce, and why AES128-CTR with personalization (and/or a DF) is not 
> sufficient.

RAND_DRBG_set() takes 2 parameters: type and flags.

Type can be:
- NID_aes_128_ctr
- NID_aes_192_ctr
- NID_aes_256_ctr

The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
is required. When not using a DF the nonce is not used.

We always use a personalization string.

The requirements for not using a DF means that you need to use
"full entropy", which is even more strict then when using a DF.
Since we don't have a "full entropy" source, we can generate it
ourself, but it would require the double amount of entropy, so 512
bit. We have no code currently to do this, but there is an open
issue about it.

There are other reasons we want to use the DF by default:
- We might have entropy sources that provide less than 8 bit of
  entropy per byte.
- We still want to support RAND_add()

The reason for the 256 bit version is that there are people that
want more than the 128 bit security level. In fact, our default
cipher order has aes-256 first. And I still read current
recommendations to use aes-256. I also read that the aes_128_ctr
DRBG might not even provide the 128 bit level, but something
much lower.


> > But I think there is at least
> enough code in there that you can write something so that the DRBG
> can be validated.
>
> But that wasn't a goal.  It *is* a goal of our next release.

So because it's not a goal to provide SM2/SM3/SM4, we don't care
that it's actually implemented properly? It's enough to just have
that name, and might do something totally different?

You also argue that because we agreed to TLS 1.3, that AES must
also be properly implemented? Doesn't it also require a proper
RNG? Or can we just call rand()?

> > - It is probably not appropriate in an API/ABI compatible 
> release
> > - It is not appropriate for a "silent change"
> 
> I'm not sure what you're talking about with the last 2 items. What
> changes are you talking about?
> 
> The fact that 384 bits of seed are needed, when before it was 128.

The previous release was 256, not 128.

> >getrandom() when available avoids this a little. But glibc in
> Debian stable is only at glibc 2.24 while 2.25 is needed. I think
> we should consider having support for the syscall ourself. We
> should probably also add support for such functions on *BSD.
>   
> So this is now a break change for debian stable?

Stable has 1.1.0 (and 1.0.2) and will most likely stay on 1.1.0.
But people will want to use TLS 1.3, so I will at least provide it
in backports. And unless we add support for the syscall, it will
probably come with some warning.

>  All the more reason to revert it.

You mean remove the whole DRBG? Or the reseeding?

(The 384 vs 256 really doesn't have any effect on /dev/urandom not
being in a chroot.)

> In going from 1.1.0 to 1.1.1, breaking platforms that used to work is just 
> plain wrong.

So then I suggest we support the syscalls on all platforms that
provide it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

2018-04-07 Thread Richard Levitte 
In message <20180407174527.gc20...@roeckx.be> on Sat, 7 Apr 2018 19:45:28 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
kurt> > In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 
18:00:32 +0200, Kurt Roeckx  said:
kurt> > 
kurt> > kurt> If you have such a program that collects the bits, I would like
kurt> > kurt> to review it. I would also like to test something like that over
kurt> > kurt> a range of machines it's expected to run on.
kurt> > 
kurt> > Errr  I have no idea what you're talking about.  I know of no
kurt> > other operating system that provides the system services VMS does, so
kurt> > I wonder how you expect to run the program gathering those data on
kurt> > anything other than VMS.
kurt> 
kurt> I mean multiple VMS machines on different processors / hardware.

VMS exists for Alpha and Itanium for the moment.  VSI is working on a
x86_64 port, with the first early adopters kit available late this
year (see http://www.vmssoftware.com/pdfs/VSI_Roadmap_20171215.pdf)

Cheers,
Richard

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

Re: [openssl-project] Entropy seeding the DRBG

2018-04-07 Thread Kurt Roeckx 
On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
> In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32 
> +0200, Kurt Roeckx  said:
> 
> kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> kurt> > > Can I suggest you try something like
> kurt> > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> kurt> > > get an idea? You would need to sample 1 variable and feed that into
> kurt> > > it.
> kurt> > 
> kurt> > And yeah, sure, especially if all it takes is to produce a stream of
> kurt> > bits from a source and feed that to the assessment program.  As long
> kurt> > as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> kurt> > the existing C++ compiler hasn't had a real update for quite a while
> kurt> > :-/ (I'm sure that VSI is quite busy updating all they can, but they
> kurt> > haven't let anything out yet)
> kurt> 
> kurt> You only need to generate the bits on VMS, you can run the tool on
> kurt> some other machine.
> 
> Cool.
> 
> kurt> If you have such a program that collects the bits, I would like
> kurt> to review it. I would also like to test something like that over
> kurt> a range of machines it's expected to run on.
> 
> Errr  I have no idea what you're talking about.  I know of no
> other operating system that provides the system services VMS does, so
> I wonder how you expect to run the program gathering those data on
> anything other than VMS.

I mean multiple VMS machines on different processors / hardware.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Kurt Roeckx 
On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 
> +0200, Kurt Roeckx  said:
> 
> kurt> | For case 2 above, the timestamp must be trusted. A trusted
> kurt> | timestamp is generated and signed by an entity that is trusted
> kurt> | to provide accurate time information.
> kurt> 
> kurt> Case 1 requires an approved random bit generator, which we don't
> kurt> have by default.
> kurt> 
> kurt> Case 2 requires the timestamp to be trusted. I think that applies
> kurt> to case 4 too. This is also something we can't do by default.
> 
> I'm not sure what you mean with "trusted"...

It's right there in the quoted text, it needs to be signed.

But I wonder how that it supposed to really work. If you want to
avoid a replay attack, does that mean you need to use a nonce? Do
we bootstrap problem?

> kurt> I think case 3 requires us keep a counter even after restarting
> kurt> the application, which seems unlikely that we will implement it.
> kurt> 
> kurt> So by default we can't do any of them. But you can argue that we
> kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now.
> 
> H...  case 4 shouldn't pose too much problems unless you restart
> the application more than once every second or so (for a 1 second
> resolution).  On VMS, the system time is kept with 100 nanosecond
> granularity...  this doesn't mean that it's actually updated every 100
> nanosecond, but the possibility is there when VMS runs on fast enough
> hardware (a VAX is decidedly not in that range, Alpha has a minimum
> update rate of 1ms, Itaniums are faster than most Alphas...).  Either
> way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
> counter to match the 128 bit nonce requirement, do I get that right?

What is not clear to me is that all DRBGs (the 1+2N) need to have
a unique nonce or not. The 3 first are all most likely to be
instantiated very close to each other. It might be that the
requirement is the nonce for all 3 is different. If you combine
this with a counter (case 4), it's easy to do this on a per
process basis, even if the time is only updated once per second.

But maybe the requirement can be over multiple processes? I really
don't know enough about this.

> kurt> I think we can do case 2 with something like gettimeofday() or
> kurt> clock_gettime() which I think provide plenty of resolution
> kurt> that it's unlikely to repeat.
> kurt> 
> kurt> You can combine that with a counter to get case 4 if you really
> kurt> wanted.
> kurt> 
> kurt> All you have to do is implement a get_nonce() function and set
> kurt> it by default. You can keep the behaviour that if no get_nonce
> kurt> function is set that it increases the entropy requirement.
> 
> Aha ok!  Yeahok, I see, so if I implement a rand_drbg_get_nonce in
> rand_vms.c, we're basically set...  but that means we need to
> implement a generic one as well, no?

It might be a little strange that the default is different on
different platforms, but I don't see why that should be a problem.
But having a generic one is probably more useful to a VMS specific
one.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Kurt Roeckx 
On Sat, Apr 07, 2018 at 04:48:51PM +, Salz, Rich wrote:
> >Like I said in the post I just made, I see zero problems with having
> that requirement on systems that can support it.  I don't see why we
> must lower the bar for *everyone* just because we currently need to do
> so for VMS
>   
> Because
>   - It is not clear we need to do so

That we need to do what?

>   - We are not required to do FIPS level DRBG/CSPRNG this release

It's not because we don't have a requirement that it can be
validated, that we should only implement it half. There are
reasons for those requirements, and they are valid even if you
don't validate it.

There are things we will not be able to do by default, because the
OS does not provide what is needed. But I think there is at least
enough code in there that you can write something so that the DRBG
can be validated.

>   - It is probably not appropriate in an API/ABI compatible release
>   - It is not appropriate for a "silent change"

I'm not sure what you're talking about with the last 2 items. What
changes are you talking about?

What I think might come more as something that breaks things is
that we now periodically reseed. It's not good enough anymore to
have /dev/urandom available at the start and before you chroot, it
now also needs to be available after you chroot. Our use of
getrandom() when available avoids this a little. But glibc in
Debian stable is only at glibc 2.24 while 2.25 is needed. I think
we should consider having support for the syscall ourself. We
should probably also add support for such functions on *BSD.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Salz, Rich 


>NIST SP800-90A rev1 section 8.6.7 has:

Compliance with this was never a stated goal of this release.  So not relevant.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

2018-04-07 Thread Richard Levitte 
In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
kurt> > > Can I suggest you try something like
kurt> > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
kurt> > > get an idea? You would need to sample 1 variable and feed that into
kurt> > > it.
kurt> > 
kurt> > And yeah, sure, especially if all it takes is to produce a stream of
kurt> > bits from a source and feed that to the assessment program.  As long
kurt> > as I don't have to port a C++11 program to VMS, 'cause unfortunately,
kurt> > the existing C++ compiler hasn't had a real update for quite a while
kurt> > :-/ (I'm sure that VSI is quite busy updating all they can, but they
kurt> > haven't let anything out yet)
kurt> 
kurt> You only need to generate the bits on VMS, you can run the tool on
kurt> some other machine.

Cool.

kurt> If you have such a program that collects the bits, I would like
kurt> to review it. I would also like to test something like that over
kurt> a range of machines it's expected to run on.

Errr  I have no idea what you're talking about.  I know of no
other operating system that provides the system services VMS does, so
I wonder how you expect to run the program gathering those data on
anything other than VMS.

If you wanna know what I'm talking about, just have a look at this
page:

http://h41379.www4.hpe.com/doc/84final/4527/4527pro_contents.html

Every "command" that starts with a '$' is a system service.  The C API
has them prefixed with 'sys$'.  The one of hightes interest seems to
be $GETRMI (or sys$getrmi), which has all sorts of counters and other
data.

kurt> I wonder if it's useful to have a thread of VMS that collects
kurt> such bits all the time, like the kernel is doing.

I was pondering something like that, and it does make sense.  That, or
creating a generic device driver (RND0:) that works a bit like the
random driver on Linux, or perhaps the one from OpenBSD...

kurt> I'm going to guess that the 4 bit you count now is an overestimate.

Don't look at me, it was I who made that estimate...  but I agree with
your guess.

kurt> And I would like to be very conservative in estimating something
kurt> like that, and even divide what the tool returns by 10.

That's a reason I want to go for a computed estimate instead...  the
3rd order delta that Linux' random driver does with jiffies seemed
like a simple enough strategy.

Cheers,
Richard

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

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Richard Levitte 
In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 02:15:51PM +, Salz, Rich wrote:
kurt> > I would like to see this put on hold until we fix the ‘now requires 50% 
more random seeding’ issue.
kurt> > 
kurt> > What should I do to force that issue?
kurt> 
kurt> NIST SP800-90A rev1 section 8.6.7 has:
kurt> | A nonce may be required in the construction of a seed during
kurt> | instantiation in order to provide a security cushion to block
kurt> | certain attacks. The nonce shall be either:
kurt> |
kurt> | a. A value with at least (security_strength/2) bits of entropy, or
kurt> | b. A value that is expected to repeat no more often than a
kurt> | (security_strength/2)-bit random string would be expected to repeat.
kurt> |
kurt> | Each nonce shall be unique to the cryptographic module in which
kurt> | instantiation is performed, but need not be secret. When used, the
kurt> | nonce shall be considered to be a critical security parameter.
kurt> |
kurt> | A nonce may be composed of one (or more) of the following
kurt> | components (other components may also be appropriate):
kurt> | 1. A random value that is generated anew for each nonce, using an
kurt> | approved random bit generator.
kurt> | 2. A timestamp of sufficient resolution (detail) so that it is
kurt> | different each time it is used.
kurt> | 3. A monotonically increasing sequence number, or
kurt> | 4. A combination of a timestamp and a monotonically increasing
kurt> | sequence number, such that the sequence number is reset when and
kurt> | only when the timestamp changes. For example, a timestamp may show
kurt> | the date but not the time of day, so a sequence number is appended
kurt> | that will not repeat during a particular day.
kurt> |
kurt> | For case 1 above, the random value could be acquired from the same
kurt> | source and at the same time as the entropy input. In this case,
kurt> | the seed could be considered to be constructed from an
kurt> | “extra strong” entropy input and the optional personalization
kurt> | string, where the entropy for the entropy input is equal to or
kurt> | greater than (3/2 security_strength) bits.
kurt> |
kurt> | For case 2 above, the timestamp must be trusted. A trusted
kurt> | timestamp is generated and signed by an entity that is trusted
kurt> | to provide accurate time information.
kurt> 
kurt> Case 1 requires an approved random bit generator, which we don't
kurt> have by default.
kurt> 
kurt> Case 2 requires the timestamp to be trusted. I think that applies
kurt> to case 4 too. This is also something we can't do by default.

I'm not sure what you mean with "trusted"...

kurt> I think case 3 requires us keep a counter even after restarting
kurt> the application, which seems unlikely that we will implement it.
kurt> 
kurt> So by default we can't do any of them. But you can argue that we
kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now.

H...  case 4 shouldn't pose too much problems unless you restart
the application more than once every second or so (for a 1 second
resolution).  On VMS, the system time is kept with 100 nanosecond
granularity...  this doesn't mean that it's actually updated every 100
nanosecond, but the possibility is there when VMS runs on fast enough
hardware (a VAX is decidedly not in that range, Alpha has a minimum
update rate of 1ms, Itaniums are faster than most Alphas...).  Either
way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
counter to match the 128 bit nonce requirement, do I get that right?

kurt> I think we can do case 2 with something like gettimeofday() or
kurt> clock_gettime() which I think provide plenty of resolution
kurt> that it's unlikely to repeat.
kurt> 
kurt> You can combine that with a counter to get case 4 if you really
kurt> wanted.
kurt> 
kurt> All you have to do is implement a get_nonce() function and set
kurt> it by default. You can keep the behaviour that if no get_nonce
kurt> function is set that it increases the entropy requirement.

Aha ok!  Yeahok, I see, so if I implement a rand_drbg_get_nonce in
rand_vms.c, we're basically set...  but that means we need to
implement a generic one as well, no?

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

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Salz, Rich 
>Like I said in the post I just made, I see zero problems with having
that requirement on systems that can support it.  I don't see why we
must lower the bar for *everyone* just because we currently need to do
so for VMS
  
Because
- It is not clear we need to do so
- We are not required to do FIPS level DRBG/CSPRNG this release
- It is probably not appropriate in an API/ABI compatible release
- It is not appropriate for a "silent change"


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

2018-04-07 Thread Kurt Roeckx 
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> > Can I suggest you try something like
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> > get an idea? You would need to sample 1 variable and feed that into
> > it.
> 
> And yeah, sure, especially if all it takes is to produce a stream of
> bits from a source and feed that to the assessment program.  As long
> as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> the existing C++ compiler hasn't had a real update for quite a while
> :-/ (I'm sure that VSI is quite busy updating all they can, but they
> haven't let anything out yet)

You only need to generate the bits on VMS, you can run the tool on
some other machine.

If you have such a program that collects the bits, I would like to
review it. I would also like to test something like that over a
range of machines it's expected to run on.

I wonder if it's useful to have a thread of VMS that collects such
bits all the time, like the kernel is doing.

I'm going to guess that the 4 bit you count now is an overestimate.
And I would like to be very conservative in estimating something
like that, and even divide what the tool returns by 10.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Richard Levitte 
Like I said in the post I just made, I see zero problems with having
that requirement on systems that can support it.  I don't see why we
must lower the bar for *everyone* just because we currently need to do
so for VMS

Cheers,
Richard

In message <116a311c-48b3-4181-9e68-b2fcc8d2d...@akamai.com> on Sat, 7 Apr 2018 
14:15:51 +, "Salz, Rich"  said:

rsalz> I would like to see this put on hold until we fix the ‘now requires 50% 
more random seeding’ issue.
rsalz> 
rsalz> What should I do to force that issue?
rsalz> 
rsalz> From: Richard Levitte 
rsalz> Reply-To: openssl/openssl
rsalz> 

rsalz> 
rsalz> Date: Saturday, April 7, 2018 at 7:36 AM
rsalz> To: openssl/openssl 
rsalz> Cc: Subscribed 
rsalz> Subject: [openssl/openssl] VMS: lower the entropy demand for this 
platform specifically (#5904)
rsalz> 
rsalz> Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
rsalz> bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
rsalz> bits for the nonce demands 384 bits of entropy. Obviously, this makes
rsalz> anything random related to fail on VMS.
rsalz> 
rsalz> The solution for now, until we get the VMS rand_pool_acquire_entropy()
rsalz> to deliver more entropy, is to lower the bar for VMS specifically,
rsalz> i.e. making the default scrambling cipher AES-128-CTR instead of
rsalz> AES-256-CTR.
rsalz> 
rsalz> Fixes #5849
rsalz> 
rsalz> 
---
rsalz> 
rsalz> You can view, comment on, or merge this pull request online at:
rsalz> 
rsalz> https://github.com/openssl/openssl/pull/5904
rsalz> 
rsalz> Commit Summary
rsalz> 
rsalz> * VMS: lower the entropy demand for this platform specifically
rsalz> 
rsalz> File Changes
rsalz> 
rsalz> * M include/openssl/rand_drbg.h (10)
rsalz> 
rsalz> Patch Links:
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.patch
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.diff
rsalz> 
rsalz> ―
rsalz> You are receiving this because you are subscribed to this thread.
rsalz> Reply to this email directly, view it on GitHub, or mute the thread.
rsalz> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Salz, Rich 
I would like to see this put on hold until we fix the ‘now requires 50% more 
random seeding’ issue.

What should I do to force that issue?

From: Richard Levitte 
Reply-To: openssl/openssl 

Date: Saturday, April 7, 2018 at 7:36 AM
To: openssl/openssl 
Cc: Subscribed 
Subject: [openssl/openssl] VMS: lower the entropy demand for this platform 
specifically (#5904)


Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
bits for the nonce demands 384 bits of entropy. Obviously, this makes
anything random related to fail on VMS.

The solution for now, until we get the VMS rand_pool_acquire_entropy()
to deliver more entropy, is to lower the bar for VMS specifically,
i.e. making the default scrambling cipher AES-128-CTR instead of
AES-256-CTR.

Fixes 
#5849


You can view, comment on, or merge this pull request online at:

  
https://github.com/openssl/openssl/pull/5904

Commit Summary

  *   VMS: lower the entropy demand for this platform specifically

File Changes

  *   M 
include/openssl/rand_drbg.h
 (10)

Patch Links:

  *   
https://github.com/openssl/openssl/pull/5904.patch
  *   
https://github.com/openssl/openssl/pull/5904.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub,
 or mute the 
thread.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-07 Thread Richard Levitte 
In message <20180406170540.gk80...@mit.edu> on Fri, 6 Apr 2018 12:05:43 -0500, 
Benjamin Kaduk  said:

kaduk> On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
kaduk> > > This is one reason why keeping around old assembly code can have a 
cost. :(
kaduk> > > 
kaduk> > > https://github.com/openssl/openssl/pull/5320
kaduk> > 
kaduk> > There is nothing I can add to what I've already said. To quote myself.
kaduk> > "None of what I say means that everything *has to* be kept, but as
kaduk> > already said, some of them serve meaningful purpose..."
kaduk> > 
kaduk> > Well, I also said that "I'm *not* saying that bit-rot is not a concern,
kaduk> > only that it's not really assembly-specific." And I can probably add
kaduk> > something here, in addition to already mentioned example of legacy code
kaduk> > relying on formally undefined or implementation-specific behaviour. 
It's
kaduk> > not actually that uncommon that *new* C code is committed[!!!]
kaduk> > "bit-rotten". So one can *just as well* say that supporting another
kaduk> > operating system has a cost, and so does using another compiler... Why
kaduk> > not get "angry" about that? What's the difference really? Relevant
kaduk> 
kaduk> Yes, supporting another operating system has a cost!
kaduk> At risk of drawing Richard's ire, if we did not intend to support
kaduk> (e.g.) VMS, we might have been able to get away with not writing our
kaduk> own custom build system in favor of some "industry standard".
kaduk> Supporting non-POSIX systems (e.g., Windows) also adds overhead in
kaduk> how we implement many of our interfaces (file handling, thread
kaduk> handling, locking, randomness, etc.).

I can channel my ire, thank you ;-)

But speaking of these things, I somewhat understand where you're
coming from, and somehow, this makes me think of the way the OpenBSD
folks do things, starting with something that's purely and entirely
for OpenBSD, and then expanding it with platform ports, and that's
actually a line of thought I could live with... BUT, and yeah, that's
a bit BUT...  our layering principles currently suck enormously, and
that also adds to the total cost of maintaining stuff.  Basically, we
have a number of platform specific stuff injected in the code a little
here and there, when we really should make the effort of putting
together an architecture independent layer that anyone would much more
easily write an implementation of for whatever new platform that comes
around, and could even come as a separate porting package that someone
else provides.

In a way, the new build system that I put together is exactly meant to
be a thing that makes it easier to port to other platforms, and at
least try to make it so that port could be delivered as a separate
package.  That was always my goal, and that was also the reason I
decided to write it in perl, 'cause that language is already ported to
all kinds of platforms like no other scripting language.  Not even
python, which is actually quite well ported, reaches as far.
(auto* tools are an abomination to try to port to anything that
doesn't look like a POSIX environment.  I tried, about 20 years ago.
Cmake, which was otherwise a strong candidate i my book, has presented
some challenges to port to VMS as well...  others have tried.  I don't
know so many others that have become popular enough to be considered
"industry standards")

But going back to what I said higher up, I very much wish we had an
actual consistent architecture agnostic layer.

Cheers,
Richard

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