[Info-vax] VSI has released 9.2-1

[Simon Clubley]

On 2023-07-04, Arne Vajhøj <arne at vajhoej.dk> wrote:
>
> But it is all very generic and it does not require and special
> HW or OS functionality. Traditional SYS$GETJPIW seems fine
> (assuming all the documentation and test is done, but that is
> also a requirement for HW or OS provided functionality).
>

At this point Arne, I don't know if you are trolling or if you really
believe that because your use of highly-abstracted languages and
associated APIs means you have lost touch with how those highly-abstracted
languages and APIs are implemented.

Every single OS vendor I am aware of, including now VSI, implements
this stuff using a kernel module to supply the required level of quality
to user programs.

No vendor I am aware of, including even Microsoft, does entropy generation
for security purposes in purely user mode.

However, because you may be aware of something I am not, can you point
to an OS that does entropy generation in purely user mode, without access
to external entropy generators, or access to the results of internal
kernel operations, such as interrupt timings, and which meets current
security standards ?

Question: If SYS$GETJPIW was good enough, why didn't VSI just use that
instead of going straight to designing and implementing an entropy engine,
with all the work that involves ?

They have not implemented many things that have been asked for due to
resource limitations, but they have spent time implementing this because
they clearly consider it to be vital.

>From https://docs.vmssoftware.com/docs/VSI_Webinar_March_2022.pdf in the
OpenSSL section:

|Working on new entropy engine that will work with OpenSSL 3.0 to help
|facilitate FIPS 140-x compliance

|SSL3 is also a key component of VSI's security roadmap to ensure that the
|OpenVMS operating system and applications running on OpenVMS are able meet
|relevant security requirements by supporting specific features such as FIPS.

>
> The relevant parts are actually quite easy to follow.
>
> They just don't say that current VMS methodology is unacceptable.
>

Standards generally don't say that using "1234" as a combination or
"password" as a password are unacceptable either. They instead focus
on explaining _what_ is acceptable.

>>                                                              here is
>> a much more readable introduction-level document from Red Hat discussing
>> these issues from a Linux point of view:
>> 
>> https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux
>> 
>> Look at the sources Linux is using for the entropy pool. You can't duplicate
>> that in user mode without access to a kernel module (and underlying OS
>> support) to help you.
>
> It explains what Linux does.
>
> And it is not possible to do what Linux does without something in the
> OS kernel.
>
> But this was about your claim that VMS could be dropped because
> it was considered not secure by todays standards.
>
> #                                                        VMS systems
> # _WILL_ be dropped in many areas if they are regarded as no longer being
> # secure by today's standards.
>
> # To put this another way, the previous solutions for generating entropy
> # within user mode that I am aware of were not suitable by today's 
> standards.
>
> I want to know where those standards are.
>
> It is certainly not the NIST 800-90A/B/C quoted above.
>

Are you sure about that ?

> It is certainly not that Redhat article.
>
> Did you just make it up????
>

VSI consider certifying VMS against FIPS to be important and they consider
a kernel-based entropy engine to be a vital part of that. Are you saying
VSI are wrong ?

BTW, with regards to my above Microsoft reference, from the following
whitepaper:

Whitepaper - The Windows 10 random number generation infrastructure.pdf

(Google it as I am not sure if the long hex string in the URL is some
personal identifier or not).

|The primary entropy source in Windows 10 is the interrupt timings. On each
|interrupt to a CPU the interrupt hander gets the Time Stamp Count (TSC)
|from the CPU. This is typically a counter that runs on the CPU clock
|frequency; on X86 and X64 CPUs this is done using the RDTSC instruction.

[snip]

Read the rest of the section as it is very interesting and clearly even
Microsoft considers this to be way more involved than just a few calls
to the Windows version of SYS$GETJPIW as you claim above.

Simon.

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