Question posted at

> https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509&sid=07767e84ea266b91e0bb9511d966b1a6

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 2022-07-08 00:14:55 +0000, Mark Daniel said:

> Question posted at
>
>> https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509&sid=07767e84ea266b91e0bb9511d966b1a6
>>

I asked the OpenVMS developers about that back around its launch; about
why a whole new API was needed. Would have been simpler to announce an
increase to the (AFAIK then-undocumented) accuracy of $gettim.

Also pointed out the naming was wrong; that the new API was offering
better accurancy, while both old and new API offered the same precision.

For OpenSSL, not a huge fan of efforts to acquire (undocumented)
entropy from a timekeeping-related API. And OpenSSL needs better
contacts with VSI.

V8.3 is sixteen years old. If the sites are that far back and clearly
not upgrading OpenVMS, what are the chances they're also upgrading SSL?
Using an LTS interval of 10 years knocks V8.4 off the list, too.

VSI had been discussing entropy a while back, but how much of that made
it into the release? The entropy engine was listed, but I've not poked
at it. Entropy discussion, from a few years ago:

https://groups.google.com/g/comp.os.vms/c/BmIXV0gN3n8/m/mETohq6qAgAJ

Yeah; my usual hammer-lock grasp of the obvious on full display here,
of course.

Shorter URL: https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/7/22 10:09 am, Stephen Hoffman wrote:
> On 2022-07-08 00:14:55 +0000, Mark Daniel said:
>
>> Question posted at
>>
>>> https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509&sid=07767e84ea266b91e0bb9511d966b1a6
>>>

Thanks for the response Hoff.

> I asked the OpenVMS developers about that back around its launch; about
> why a whole new API was needed. Would have been simpler to announce an
> increase to the (AFAIK then-undocumented) accuracy of $gettim.
>
> Also pointed out the naming was wrong; that the new API was offering
> better accurancy, while both old and new API offered the same precision.
>
> For OpenSSL, not a huge fan of efforts to acquire (undocumented) entropy
> from a timekeeping-related API. And OpenSSL needs better contacts with VSI.

Agreed. It has become such an integral part of the OS infrastructure.

At least it seems updated releases are promptly being issued by VSI.

> V8.3 is sixteen years old. If the sites are that far back and clearly
> not upgrading OpenVMS, what are the chances they're also upgrading SSL?
> Using an LTS interval of 10 years knocks V8.4 off the list, too.

I recently updated one. Tried using the VSI latest PCSI release,
ignoring the "needs V8.4" warning, and continued on. Installed OK. IVP
failed of course. And when OPENSSL executable ACCVIOed (presumably) on
the unresolved $GETTIME_PREC. Without that it would have been fine.

Fell back to the WASD OpenSSL build which explicitly uses $GETTIM to
allow V8.4, V8.3, and presumably further back. Would be nice if WASD no
longer needed its own OpenSSL to keep current.

Then I started tinkering with dynamically loading SYS$GETTIM_PREC and if
unavailable falling back to SYS$GETTIM. Tested working for V8.4 and
V8.3 and submitted the change via an OpenSSL bug report.

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

OpenSSL used the concept with their own code which tested OK across V8.4
and V8.3.

Now the need at all for SYS$GETTIM_PREC is now being questioned. If
eliminated the V8.4 dependency goes with it.

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

Hence the question of VSI.

> VSI had been discussing entropy a while back, but how much of that made
> it into the release? The entropy engine was listed, but I've not poked
> at it.  Entropy discussion, from a few years ago:

OpenSSL are prepping for it. From...

> https://raw.githubusercontent.com/levitte/openssl/fix-18727-111/crypto/rand/rand_vms.c

Look for...

/*
* SYS$GET_ENTROPY METHOD
* ======================
*
* This is a high entropy method based on a new system service that is
* based on getentropy() from FreeBSD 12. It's only used if available,
* and its availability is detected at run-time.
*
* We assume that this function provides full entropy random output.
*/
#define PUBLIC_VECTORS "SYS$LIBRARY:SYS$PUBLIC_VECTORS.EXE"
#define GET_ENTROPY "SYS$GET_ENTROPY"
8< snip 8<

> https://groups.google.com/g/comp.os.vms/c/BmIXV0gN3n8/m/mETohq6qAgAJ
>
> Yeah; my usual hammer-lock grasp of the obvious on full display here, of
> course.
>
> Shorter URL: https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 7/7/2022 9:36 PM, Mark Daniel wrote:
> On 8/7/22 10:09 am, Stephen Hoffman wrote:
>> Also pointed out the naming was wrong; that the new API was offering
>> better accurancy, while both old and new API offered the same precision.

> Fell back to the WASD OpenSSL build which explicitly uses $GETTIM to
> allow V8.4, V8.3, and presumably further back.  Would be nice if WASD no
> longer needed its own OpenSSL to keep current.
>
> Then I started tinkering with dynamically loading SYS$GETTIM_PREC and if
> unavailable falling back to SYS$GETTIM.  Tested working for V8.4 and
> V8.3 and submitted the change via an OpenSSL bug report.
>
> https://github.com/openssl/openssl/issues/18727
>
> OpenSSL used the concept with their own code which tested OK across V8.4
> and V8.3.
>
> Now the need at all for SYS$GETTIM_PREC is now being questioned.  If
> eliminated the V8.4 dependency goes with it.
>
> https://github.com/openssl/openssl/pull/18730

> Hence the question of VSI.
>
>> VSI had been discussing entropy a while back, but how much of that
>> made it into the release? The entropy engine was listed, but I've not
>> poked at it.  Entropy discussion, from a few years ago:
>
> OpenSSL are prepping for it.  From...
>
>> https://raw.githubusercontent.com/levitte/openssl/fix-18727-111/crypto/rand/rand_vms.c
>
> Look for...
>
> /*
>  * SYS$GET_ENTROPY METHOD
>  * ======================
>  *
>  * This is a high entropy method based on a new system service that is
>  * based on getentropy() from FreeBSD 12.  It's only used if available,
>  * and its availability is detected at run-time.
>  *
>  * We assume that this function provides full entropy random output.
>  */

I am not sure that I get it.

SSL needs a large number of random bits.

Even if $GETTIM_PREC gave a few more bits than $GETTIM, then
I don't see that as a big thing - and not worth any
version ifdef's.

Arne

PS: I dabbled a little bit in the random bytes topic last year and the
result is here https://www.vajhoej.dk/arne/opensource/extran/

On 2022-07-07, Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>
> Look for...
>
> /*
> * SYS$GET_ENTROPY METHOD
> * ======================
> *
> * This is a high entropy method based on a new system service that is
> * based on getentropy() from FreeBSD 12. It's only used if available,
> * and its availability is detected at run-time.
> *
> * We assume that this function provides full entropy random output.
> */
> #define PUBLIC_VECTORS "SYS$LIBRARY:SYS$PUBLIC_VECTORS.EXE"
> #define GET_ENTROPY "SYS$GET_ENTROPY"
> 8< snip 8<
>

FINALLY!!! (I hope :-) See below.)

It is a shared system pool based on information observable at system
level, or are VSI implementing some per-process hack ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 8/7/22 9:14 am, Mark Daniel wrote:
> Question posted at
>
>> https://forum.vmssoftware.com/viewtopic.php?f=21&t=8509&sid=07767e84ea266b91e0bb9511d966b1a6
>>

The upshot of asking this question (ignoring the hypervisor element) is
that there is no (current) effective difference between the result of
the two calls. This combined with your [Richard Levitte] own SP 800-90A
section 4 observation suggests that SYS$GETTIM_PREC may be eliminated
while still maintaining compliance.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 2022-07-08 12:12:57 +0000, Arne Vajhj said:

> I am not sure that I get it.
>
> SSL needs a large number of random bits.
>
> Even if $GETTIM_PREC gave a few more bits than $GETTIM, then I don't
> see that as a big thing - and not worth any version ifdef's.

The erroneously-named $GETTIM_PREC either returns the same or fewer
undefined bits than does $GETTIM depending on context.

Both the erroneously-named $GETTIM_PREC and $GETTIM return the same precision.

VSI should probably just update $GETTIM for the available accuracy, and
de-emphasis if not deprecate the erroneously-named $GETTIM_PREC call.

But then I can't fathom an app being dependent on the undefined bits,
and here somebody seems to be considering working on one.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-07-10 20:37:38 +0000, Stephen Hoffman said:

> But then I can't fathom an app being dependent on the undefined bits,
> and here somebody seems to be considering working on one.

And it's not being used for entropy, the quadword time is being used as
a sequencer, without or probably with a serial number.

--
Pure Personal Opinion | HoffmanLabs LLC

On Friday, July 8, 2022 at 1:16:24 PM UTC-4, Simon Clubley wrote:

>
> It is a shared system pool based on information observable at system
> level, or are VSI implementing some per-process hack ?

It's a VMS adaptation (nearly a complete code lift) of the Fortuna code in FreeBSD. The V9.2 version works. V9.x prior to V9.2, the service was there but returned "random-looking" data from the well-named internal hack called fake_entropy. There will be future refinements. The entropy harvester is the portion of code that most diverges from FreeBSD and the stochastic sources differ somewhat. As a server-based OS, we don't track mouse movement, for example.

And before anyone asks, V9.2 does support the RDRAND instruction if both the hardware and hypervisor do. It's not a given and may actually vary by underlying hardware/OS for the same hypervisor. RDRAND is just of the sources hashed into pool.

On 2022-07-15, Some Dude <dgordonatvsi@gmail.com> wrote:
> On Friday, July 8, 2022 at 1:16:24 PM UTC-4, Simon Clubley wrote:
>
>>
>> It is a shared system pool based on information observable at system
>> level, or are VSI implementing some per-process hack ?
>
> It's a VMS adaptation (nearly a complete code lift) of the Fortuna code in FreeBSD. The V9.2 version works. V9.x prior to V9.2, the service was there but returned "random-looking" data from the well-named internal hack called fake_entropy. There will be future refinements. The entropy harvester is the portion of code that most diverges from FreeBSD and the stochastic sources differ somewhat. As a server-based OS, we don't track mouse movement, for example.
>

Thank you Doug. Nice to see this has made it to VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.