On 6/20/2023 1:50 PM, Simon Clubley wrote:
> On 2023-06-20, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-06-20 14:06, Simon Clubley wrote:
>>> On 2023-06-19, Johnny Billquist <bqt@softjar.se> wrote:
>>>>
>>>> I really shouldn't be adding posts to this stupid topic.
>>>>
>>>> Competing with China is nothing like a business rivalry. At some point
>>>> this needs to be addressed properly.
>>>>
>>>> https://youtu.be/0xlq4WSpUH8
>>>>
>>>
>>> How does that incident compare to what the US are doing to everyone else ?
>>
>> Can you provide some facts instead of sweeping generalizations here, please?
>>
>> You just claiming something is so don't necessarily make it true.
>> Hard to have a discussion comparing two things when one is a concrete
>> incident, and the other a sweeping generalization and opinion.
>>
>
> Not an opinion. There's plenty of stuff that's come out about what the
> US are up to. (As well as what the UK and other countries are up to).
>
> Some random examples resulting from keyword searches:
>
> 1) The US planted backdoors in Cisco equipment:
>
> https://www.infoworld.com/article/2608141/snowden--the-nsa-planted-backdoors-in-cisco-products.html
>
> Exactly the kind of thing they accuse China of doing.
>
> 2) The US secretly purchased a Swiss company and sold equipment with
> backdoors in it:
>
> https://en.wikipedia.org/wiki/Crypto_AG
> https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/
>
> Exactly the kind of thing they accuse China of doing.
>
> 3) The US violated the trust placed in it to compromise security standards:
>
> https://en.wikipedia.org/wiki/Dual_EC_DRBG
>
> Exactly the kind of thing China would like to do, but are not yet in
> a sufficient position of trust to be able to do it.
>
> 4) The US spies on close allies for economic purposes:
>
> https://www.dw.com/en/germany-fears-nsa-stole-industrial-secrets/a-16925289
> https://www.itnews.com.au/news/snowden-accuses-nsa-of-stealing-business-secrets-370704?eid=1&edate=20140128&utm_source=20140128_AM&utm_medium=newsletter&utm_campaign=daily_newsletter&eaddr=%%Email%20Address%%
>
> Exactly the kind of thing they accuse China of doing.
>
> Simon.
>

Do unto others, but, do it first ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 6/20/2023 1:18 PM, Chris Townley wrote:
> On 20/06/2023 17:55, bill wrote:
>> On 6/20/2023 11:53 AM, Dave Froble wrote:
>>> >
>>> Maybe the best thing to do is nuke the Harvard Business School? And declare
>>> open season on lawyers?
>>>
>>
>> Been there, done that.
>>
>> "First we kill all the lawyers." : Shakespeare
>>
>> We have a commercial running now where a lawyer says the biggest
>> complaint against lawyers is that they don't return phone calls.
>> Funny, I always thought the biggest complaint against lawyers was
>> that they were scum sucking bottom feeders.
>>
>> bill
>>
>
> I recall the sad story of an airliner full of lawyers that crashed, and all were
> killed.
> Everybody felt sad for the pilot

Good one!

:-)

Sometimes sacrifices are necessary ...

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <u6qp9o$26q1s$1@dont-email.me>, arne@vajhoej.dk (Arne Vajh�j)
wrote:
> On 6/19/2023 1:43 PM, Simon Clubley wrote:
> > In the old days, your military had to worry about protecting your
> > industrial base from an enemy. These days, all your enemy needs to
> > do is to threaten to stop sending you the goods they now produce
> > for you.
>
> If the goods are critical yes.
>
> But China export is mostly consumer stuff.

Last time I bought servers from IBM, they were produced in China. They
were low-to-medium range AIX boxes, about $10,000 each in about 2015.

There's also lots and lots of basic industrial supplies produced in China:
bolts, cable, switches, and so on. China has acquired vast market power
through selling stuff cheap and driving other producers out of business.

John

On Tuesday, June 20, 2023 at 9:18:03 AM UTC-4, Dave Froble wrote:
> On 6/20/2023 8:51 AM, Simon Clubley wrote:
> > On 2023-06-19, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >> On 6/19/2023 1:43 PM, Simon Clubley wrote:
> >>> That's all well and good Rob, but what happens when China grows a bit
> >>> stronger and then decides to show you who the boss is by cutting off
> >>> your imports ?
> >>
> >> Americans can no longer get cheap furniture, cheap tools and all
> >> sorts of cheap junk from China.
> >>
> >> They will survive.
> >>
> >
> > They also can't get all the medical supplies and critical equipment
> > now produced in China, and which would need a _serious_ amount of time
> > to rebuild that infrastructure within the US.
> It is my understanding that much of the medical stuff comes from India and other
> places. Don't know how much comes from China.
> > Are you sure about the above ?
> Yes, we would survive. We'd learn the lesson to not be so dependent on others,
> but, we'd just have to "onshore" what we'd let go of in the past.
> >>> That's where the US
> >>> currently gets most of its bullying power from.
> >>
> >> It doesn't really give any power.
> >>
> >
> > Yes, it does. The US is currently using its power to force its allies
> > to also impose sanctions. In a more general way, the US imposes a threat
> > of being frozen out of the US banking system to get its way.
> True.
> >>> In the old days, your military had to worry about protecting your
> >>> industrial base from an enemy. These days, all your enemy needs to
> >>> do is to threaten to stop sending you the goods they now produce
> >>> for you.
> >>
> >> If the goods are critical yes.
> >>
> >> But China export is mostly consumer stuff.
> >>
> >
> > So what happened to the supply chains during Covid was an illusion ?
> > (And that was with China still trying to meet its obligations!)
> It's a bit complex. Consider two people in a rubber life raft. They don't get
> along, so, one decides to sink the raft, to harm the other. The first person is
> also in the life raft. Both would suffer.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486
David,

If memory serves, the tale is known as "The Frog and the Scorpion". At least one book attributed it to Vietnam.

All, WADR, let us keep the politics outside of this forum. Less stuff to wade through.

- Bob Gezelter, http://www.rlgsc.com

On 20/06/2023 21:16, John Dallman wrote:
> In article <u6qp9o$26q1s$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> On 6/19/2023 1:43 PM, Simon Clubley wrote:
>>> In the old days, your military had to worry about protecting your
>>> industrial base from an enemy. These days, all your enemy needs to
>>> do is to threaten to stop sending you the goods they now produce
>>> for you.
>>
>> If the goods are critical yes.
>>
>> But China export is mostly consumer stuff.
>
> Last time I bought servers from IBM, they were produced in China. They
> were low-to-medium range AIX boxes, about $10,000 each in about 2015.
>
> There's also lots and lots of basic industrial supplies produced in China:
> bolts, cable, switches, and so on. China has acquired vast market power
> through selling stuff cheap and driving other producers out of business.
>
> John

There is a company that I invest in, Volex, which has carefully bought
into other manufacturing bases, to remove their dependency on China.
Sadly the market for some strange reason doesn't like their purchases

--
Chris

Gentlemen, and any Ladies if present:

Might I please ask you to move this topic to a relevant newsgroup?
There are dozens of alt.politics.<whatever> to choose from.

Thanks,
Mike

--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#befor

On 2023-06-20 19:28, Simon Clubley wrote:
> On 2023-06-20, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-06-20 14:51, Simon Clubley wrote:
>>>
>>> Yes, it does. The US is currently using its power to force its allies
>>> to also impose sanctions. In a more general way, the US imposes a threat
>>> of being frozen out of the US banking system to get its way.
>>
>> ??? Sanctions on Russia have not been forced on by the US. You might
>> better blame the UK in that case, which has been leading this more. Or a
>> bunch of former eastern european countries, who have various past bad
>> experiences with Russia, and know all too well what it's all about.
>>
>> What other contries are there sanctions against? North Korea. Seriously
>> - you think that the US bullied other countries into those sanctions?
>> Syria? Iran?
>>
>
> China. Please research the situation with ASML and what the US is doing
> to a European company as one example.

You are of course entitled to have your opinions. It's a free world
(some parts). And you have the right to express your opinions without
fear of reprecussions.

Let's just hope countries like China don't get too much power, or that
freedom will not be there anymore.

And now this thread should die.

Johnny

On 6/20/2023 8:29 AM, Simon Clubley wrote:
> On 2023-06-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 6/19/2023 8:20 AM, Simon Clubley wrote:
>>>
>>> This is not about selling new systems. This is about being a part of
>>> work to make sure that existing sites don't get forced to move away
>>> from VMS because VMS no longer meets the industry standard security standards.
>>>
>>> You can have a nice piece of software running on VMS, but that's no
>>> good unless those VMS systems are secure by modern standards. VMS systems
>>> _WILL_ be dropped in many areas if they are regarded as no longer being
>>> secure by today's standards.
>>
>> Which security standards mandate direct support for entropy generation
>> in the OS?
>
> You can also do it using external devices, which has been the only option
> for VMS until now, because the goal is to be able to meet a set of
> specified standards.
>
>>>> The OpenSSL maintainers may be happy that they get better entropy
>>>> with less code.
>>>
>>> Replace "better entropy" with "now-acceptable entropy".
>>
>> Who is saying that current OpenSSL way is no longer acceptable?
>
> OpenSSL on VMS, not OpenSSL in general.
>
>>> The new entropy
>>> engine running within the kernel offers a brand-new capability for VMS
>>> that is considered to be standard elsewhere.
>>>
>>> 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.
>>
>> So you say.
>>
>> I would really like to get some sources.
>>
>
> Fair enough. The current standards are the NIST SP 800-90 series of
> standards:
>
> https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final

This standard specifies in great detail how to get from
entropy to secure random bytes.

It does not specify how the entropy should be generated
(it uses an abstract function get_entropy_input for it).

> https://csrc.nist.gov/publications/detail/sp/800-90b/final

This is the relevant one.

Quotes:

<quote>
Noise sources can be divided into two categories: Physical noise sources
use dedicated hardware
to generate randomness; whereas Non-physical noise sources use system
data (such as output of
Application Programming Interface (API) functions, Random Access Memory
(RAM) data or
system time) or human input (e.g., mouse movements) to generate randomness.
</quote>

<quote>
The requirements for the noise source are as follows:
1. The operation of the noise source shall be documented; this
documentation shall include a
description of how the noise source works, where the unpredictability
comes from, and
rationale for why the noise source provides acceptable entropy output,
and should reference
relevant, existing research and literature.
2. The behavior of the noise source shall be stationary (i.e., the
probability distributions of the
noise source outputs do not change when shifted in time). Documentation
shall include why it
is believed that the entropy rate does not change significantly during
normal operation. This
can be in broad terms of where the unpredictability comes from and a
rough description of the
behavior of the noise source (to show that it is reasonable to assume
that the behavior is
stationary).
3. Documentation shall provide an explicit statement of the expected
entropy provided by the
noise source outputs and provide a technical argument for why the noise
source can support
that entropy rate. To support this, documentation may include a
stochastic model of the noise
source outputs, and an entropy estimation based on this stochastic model
may be included.
4. The noise source state shall be protected from adversarial knowledge
or influence to the
greatest extent possible. The methods used for this shall be documented,
including a
description of the (conceptual) security boundary’s role in protecting
the noise source from
adversarial observation or influence.
5. Although the noise source is not required to produce unbiased and
independent outputs, it shall
exhibit random behavior; i.e., the output shall not be definable by any
known algorithmic rule.
Documentation shall indicate whether the noise source produces IID data
or non-IID data. This
claim will be used in determining the test path followed during
validation. If the submitter
makes an IID claim, documentation shall include rationale for the claim.
6. The noise source shall generate fixed-length bitstrings. A
description of the output space of
the noise source shall be provided. Documentation shall specify the
fixed symbol size (in bits)
and the list (or range) of all possible outputs from each noise source.
7. If additional noise source outputs to increase security are used, a
document that describes the
additional noise sources shall be included.
</quote>

(it also contains a lot about how to test noise)

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

> https://csrc.nist.gov/publications/detail/sp/800-90c/draft

(that is still a draft)

Just like 90A it does not cover the entropy but just refer to
an abstract GetEntropy function and 90B.

> In each case, the actual standard can be found in the top right of the
> page, under the "Publication:" section.
>
> However, since they can be hard to follow in certain parts,

The relevant parts are actually quite easy to follow.

They just don't say that current VMS methodology is unacceptable.

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

It is certainly not that Redhat article.

Did you just make it up????

>>> Maybe I am seeing something here you are missing ?
>>
>> Possible. I miss a lot of things. So just post links
>> to the standards, best practice documents etc. specifying
>> the need for direct OS entropy.
>>
>
> The NIST and earlier standards specify a series of requirements. You can't
> meet those requirements in a software-based solution without kernel support
> to get direct access to the entropy sources.

No.

That is not what the NIST standards say.

Arne

On 6/19/2023 9:43 PM, Dave Froble wrote:
> People who count for encryption to provide protection don't really care
> all that much.  Do enough to check the appropriate box, then not their
> problem.
>
> People who really care about security of course may use SSL, but then
> what happens when the encryption is broken?  The user's data is
> available to the hackers.  But what if the app developers insured that
> the data, if encryption is defeated, doesn't really mean anything to the
> hackers.  Some custom stuff in addition to SSL and such.  Yeah, even
> then, some hacker might figure out the data.  But isn't it better to
> make it as tough for the hacker as one can?
>
> Now I'll hear from some "you got to use standards".  I'd ask "why?"  The
> problem with standards is, everybody knows them.

There are two benefits from going standard.

Interoperability. If the communication is based on standards, then
software from different vendors can communicate. SSL (TLS 1.2 or 1.3
of course!) is widely supported standard so C programs on VMS,
Java programs on Linux and VB.NET programs on Windows can communicate
without problems due to the standard.

Security. The public known standard protocols and algorithms are being
reviewed by thousands of mathematicians all over the world. A home grown
protocol and algorithm will be reviewed by a few software engineers
which may or may not have math/cryptography knowledge. The first will
simply result in a better solution.

Good cryptography does not depend on protocols or algorithms
being unknown. It is possible to constructs stuff that are secure
even with known protocols/algorithms. And protocols/algorithms
that are not secure if known are very bad. They will eventually leak.

Arne

On 7/4/2023 9:25 PM, Arne Vajhøj wrote:
> On 6/19/2023 9:43 PM, Dave Froble wrote:
>> People who count for encryption to provide protection don't really care all
>> that much. Do enough to check the appropriate box, then not their problem.
>>
>> People who really care about security of course may use SSL, but then what
>> happens when the encryption is broken? The user's data is available to the
>> hackers. But what if the app developers insured that the data, if encryption
>> is defeated, doesn't really mean anything to the hackers. Some custom stuff
>> in addition to SSL and such. Yeah, even then, some hacker might figure out
>> the data. But isn't it better to make it as tough for the hacker as one can?
>>
>> Now I'll hear from some "you got to use standards". I'd ask "why?" The
>> problem with standards is, everybody knows them.
>
> There are two benefits from going standard.
>
> Interoperability. If the communication is based on standards, then
> software from different vendors can communicate. SSL (TLS 1.2 or 1.3
> of course!) is widely supported standard so C programs on VMS,
> Java programs on Linux and VB.NET programs on Windows can communicate
> without problems due to the standard.
>
> Security. The public known standard protocols and algorithms are being
> reviewed by thousands of mathematicians all over the world. A home grown
> protocol and algorithm will be reviewed by a few software engineers
> which may or may not have math/cryptography knowledge. The first will
> simply result in a better solution.
>
> Good cryptography does not depend on protocols or algorithms
> being unknown. It is possible to constructs stuff that are secure
> even with known protocols/algorithms. And protocols/algorithms
> that are not secure if known are very bad. They will eventually leak.
>
> Arne
>

You sort of missed the point of my post.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Tuesday, June 20, 2023 at 11:52:50 AM UTC-4, Dave Froble wrote:
> On 6/20/2023 10:18 AM, Single Stage to Orbit wrote:
> > On Tue, 2023-06-20 at 09:18 -0400, Dave Froble wrote:
> >> Yes, we would survive. We'd learn the lesson to not be so dependent
> >> on others, but, we'd just have to "onshore" what we'd let go of in
> >> the past.
> >
> > Greed. I call it pure unalternated greed on the part of Wall Street.
> > Squeezing us dry for profit. The UK is already hurtling along the same
> > path that the US has already trod upon. Western Europe isn't that
> > stupid, well mostly.
> >
> It's a rather complex situation.
>
> "Greed" can be helpful, if it causes good things to happen. But it will usually
> be harmful to some. Case, the take over of North America, good for some, but
> not so good for the native americans.
>
> I consider myself a bit conservative, but, nothing like the current definition
> of conservative in the US. I don't think I'm a socialist, but, I think
> government should "do the right thing" without resorting to names. Perhaps it's
> the names that are the problem.
>
> For example, Bernie Sanders, who called himself a "socialist" and tried to run
> for president. Now, I'm betting over 90% of voters in the US don't understand
> just what socialism might be, but, I'm sure over 90% of voters in the US "know"
> that socialism is BAD. Why couldn't the idiot just say what he is for, things
> that I'd approve of, and ignore the name. Like shooting yourself in the foot,
> and taking out the rest of yourself.
>
> Then there is "woke", whatever that is.
>
> Maybe the best thing to do is nuke the Harvard Business School? And declare
> open season on lawyers?
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

Keynesian economics always fail ... just ask Japan.

On Monday, June 19, 2023 at 5:29:57 PM UTC-4, Dave Froble wrote:
> On 6/19/2023 11:57 AM, Johnny Billquist wrote:
> > On 2023-06-19 16:41, Pizza RAC wrote:
> >> On Thursday, June 15, 2023 at 6:43:08 PM UTC-4, Jan-Erik Söderholm wrote:
> >>>
> >>> Now, my last VMS work seem to have come to an end the 30th June.
> >>> So I'll probably never be able to work with this new VMS version.
> >>> I was 64 in may -23 so I will probably simple retire...
> >>>
> >>> Ah well, 30+ years with VMS is not that bad anyway... :-)
> >>>
> >>> Jan-Erik.
> >>
> >> come to the U.S. with Biden in charge no one will ever be able to retire :)
> >
> > Yeah. I guess that concept only exist in socialist countries, like Sweden.
> I think that is also possible in a possibly non-socialist country, but it sure
> isn't helped by fascist Republicans, and the US seems to growing some of them.
>
> I know this isn't the venue for politics. But I grow tired of seeing the same
> old thing over and over again. One would think that supposedly intellegent
> humans would sooner or later learn. But apparently not.
>
> In the 1930s a great evil arose. Many bad things happened. And now, 90 years
> later, it's happening again.
>
> Racism in the US and elsewhere.
>
> We see attempts to silence political opponents in other countries, but that
> would never happen in the USA, right? Too bad nobody mentioned that to the
> "dangerous" idiot in Florida.
>
> I guess some in Israel feel it's their turn, and are doing to the Palestinians
> what the Nazis did to them. Wonder when they will schedule their "crystal night".
>
> But the biggest thing I'm really pissed off about, "find me 11,800 votes"..
>
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

someone called the antichrist is going to appear very soon. He will deceive many into following him.

End times ...

In article <u6r05u$2b1q4$1@dont-email.me>, davef@tsoft-inc.com (Dave
Froble) wrote:

> People who really care about security of course may use SSL, but
> then what happens when the encryption is broken? The user's data
> is available to the hackers. But what if the app developers
> insured that the data, if encryption is defeated, doesn't really
> mean anything to the hackers. Some custom stuff in addition to SSL
> and such. Yeah, even then, some hacker might figure out the data.
> But isn't it better to make it as tough for the hacker as one can?
>
> Now I'll hear from some "you got to use standards". I'd ask "why?"
> The problem with standards is, everybody knows them.

The SSL standards, and the TLS standards that have succeeded them, do
something that's actually quite hard, which is to let two ends of a
communication link agree on an encryption key without ever passing that
key over the link, or having any kind of default key or other shared
secret.

They do that part via cleverness with public-key encryption, and use it
to agree on a key for symmetric encryption. Those are significantly
different kinds of encryption: you can't do the key-agreement part in a
practical way with only symmetric encryption, and public-key encryption
is too slow for sending any volume of data.

<https://en.wikipedia.org/wiki/Public-key_cryptography>
<https://en.wikipedia.org/wiki/Symmetric-key_algorithm>
<https://en.wikipedia.org/wiki/Transport_Layer_Security>

Note that you do get to tell your end of the TLS link what public- and
symmetric algorithms you are willing for it to use, and what key lengths
you demand. If the other end can't meet your demands, you can't
communicate, but that's failing to the secure case.

The main reason for using standard TLS, rather than creating your own
version, is that doing that right is /hard/, and anyone doing it
themselves is certain, at a practical level, to create something worse
than TLS.

The standards have been reviewed and attacked by large numbers of experts
over years. Versions 1.0, 2.0 and 3.0 of SSL have been cracked and
deprecated; versions 1.0 and 1.1 of TLS are also cracked and deprecated.
TLS 1.2 has vulnerabilities that are currently difficult to exploit and
will be deprecated in the next few years; TLS 1.3 is currently sound.

Cracks of those standards aren't a question of finding out how to read a
secret code or cipher that they use, or cracking public-key encryption,
but of finding flaws in the way that they /use/ public-key encryption so
as to give clues about the (entirely random) symmetric encryption key
that they are used to agree on. Those standards are treated as cracked as
soon as a way to get significant information about the negotiated key is
published. That doesn't mean that everything sent over them has become
readable: being able to discover a few bits of a 128- or 256-bit key is a
"crack." Thereby, they are deprecated long before breaking them becomes
practical.

Now, using additional encryption on the data you're sending over TLS is
certainly possible. However, it isn't all that practical. You need to
agree an encryption key between the two ends. You can do that via
communication through the TLS link, but if that's being read by an
opponent, they just got the key you're about to use for your data.

If you do TLS-through-TLS, that could work, provided the TLS you're using
is not cracked. But it's just easier to use a single layer of TLS and
require it to use longer public keys and stronger symmetric algorithms.

The secondary reason for using standard TLS is that it allows you to
communicate with anything else that uses it. Other implementations, other
operating systems, and so on.

Now, that may not be important to you. You may be building a system where
only specific computers are to communicate with each other. It is still
worth considering using standard TLS, for several reasons:

* The protocols are very likely better than anything home-built.
* If the TLS protocols are cracked, you'll hear about it early on.
* If a homebrew protocol is cracked, your opponent won't tell you.
* Distributing symmetric keys any other way is harder.

Alternative ways of distributing keys require sending some kind of
computer-readable physical medium. It needs to be hard to copy, and it
needs to arrive /very/ reliably. If your system won't be in use long,
this may be practical.

How do you tell which public-key and symmetric algorithms are good?
Knowledge of the field.

The current gold standard for symmetric is the Advanced Encryption
Standard, which is approved by the NSA for Top Secret information.
<https://en.wikipedia.org/wiki/Advanced_Encryption_Standard>

The current gold standard for public-key is RSA with a key of 4096 bits
or longer. This is currently expected to be menaced by quantum computers
within a decade, and the NSA is starting a transition to post-quantum
cryptography. For now, it's the best we have and is very unlikely to be
broken soon.

John

On 2023-07-04, Arne Vajhøj <arne@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@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 7/5/2023 9:05 AM, Dave Froble wrote:
> On 7/4/2023 9:25 PM, Arne Vajhøj wrote:
>> On 6/19/2023 9:43 PM, Dave Froble wrote:
>>> People who count for encryption to provide protection don't really
>>> care all
>>> that much.  Do enough to check the appropriate box, then not their
>>> problem.
>>>
>>> People who really care about security of course may use SSL, but then
>>> what
>>> happens when the encryption is broken?  The user's data is available
>>> to the
>>> hackers.  But what if the app developers insured that the data, if
>>> encryption
>>> is defeated, doesn't really mean anything to the hackers.  Some
>>> custom stuff
>>> in addition to SSL and such.  Yeah, even then, some hacker might
>>> figure out
>>> the data.  But isn't it better to make it as tough for the hacker as
>>> one can?
>>>
>>> Now I'll hear from some "you got to use standards".  I'd ask "why?"  The
>>> problem with standards is, everybody knows them.
>>
>> There are two benefits from going standard.
>>
>> Interoperability. If the communication is based on standards, then
>> software from different vendors can communicate. SSL (TLS 1.2 or 1.3
>> of course!) is widely supported standard so C programs on VMS,
>> Java programs on Linux and VB.NET programs on Windows can communicate
>> without problems due to the standard.
>>
>> Security. The public known standard protocols and algorithms are being
>> reviewed by thousands of mathematicians all over the world. A home grown
>> protocol and algorithm will be reviewed by a few software engineers
>> which may or may not have math/cryptography knowledge. The first will
>> simply result in a better solution.
>>
>> Good cryptography does not depend on protocols or algorithms
>> being unknown. It is possible to constructs stuff that are secure
>> even with known protocols/algorithms. And protocols/algorithms
>> that are not secure if known are very bad. They will eventually leak.
>
> You sort of missed the point of my post.

I miss a lot.

But I read it as that you suggested not using standard
protocols/algorithms but something unique/homemade.

Was that not the case?

Arne

On 7/5/2023 10:39 AM, John Dallman wrote:
> How do you tell which public-key and symmetric algorithms are good?
> Knowledge of the field.
>
> The current gold standard for symmetric is the Advanced Encryption
> Standard, which is approved by the NSA for Top Secret information.

Yes.

> The current gold standard for public-key is RSA with a key of 4096 bits
> or longer.

I think the ECC stuff is also very widely used today.

Regrading RSA key size then I think NIST and OWASP still just
recommends >=2048. My impression is that the IT industry
often goes for 3072. 4096 is very good.

Arne

On 7/5/2023 2:23 PM, Simon Clubley wrote:
> On 2023-07-04, Arne Vajhøj <arne@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.

I don't think my preference for programming languages are particular
relevant for whether your claims of:

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

are correct or not.

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

Using HW/OS is definitely what is being done for new OS versions.

But there is a difference from that and the old way not being
acceptable.

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

The question was not whether using HW/OS is good. I think everybody
agrees it is.

The question was whether not using HW/OS would cost VMS sales now
due to being not compliant.

It is hardly surprising that VSI is implementing new functionality
looking forward instead of backwards.

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

That is actually interesting.

Per:

https://www.openssl.org/docs/fips.html
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282

then OpenSSL is FIPS 140-2 certified on:

<quote>
Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86)
without PAA
FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64)
without PAA
macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64)
without PAA
macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA
(single-user mode)
Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
i7(x64) with PAA
Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
i7(x64) without PAA
Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without PAA
</quote>

Maybe VSI want VMS on that list.

But that list is not the server market.

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

Yes.

But old practices seems to match the description of what is acceptable.

I actually copied the text in. You just omitted it when replying.

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

I quoted the text. You tell me what lines old OpenSSL does not match.

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

If VSI believe they need FIPS certification and that they need the new
better entropy to get that, then it all makes sense.

But if you check the list above then FIPS certification does not
seem to be a requirements to sell servers today.

Among other things then Redhat Linux is not on the list.

(even though I believe they are in the process of getting certified)

Arne

On 7/5/2023 4:33 PM, Arne Vajhøj wrote:
> On 7/5/2023 2:23 PM, Simon Clubley wrote:
>>  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.
>
> That is actually interesting.
>
> Per:
>
> https://www.openssl.org/docs/fips.html
> https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
>
> then OpenSSL is FIPS 140-2 certified on:
>
> <quote>
>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86)
> without PAA
>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64)
> without PAA
>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64)
> without PAA
>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA
> (single-user mode)
>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
> i7(x64) with PAA
>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
> i7(x64) without PAA
>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without
> PAA
> </quote>
>
> Maybe VSI want VMS on that list.

But I wonder.

How will VSI get FIPS 140-2 certification for VMS x86-64 if they only
support running in VM not on physical hardware??

Arne

On 7/5/2023 3:37 PM, Arne Vajhøj wrote:
> On 7/5/2023 9:05 AM, Dave Froble wrote:
>> On 7/4/2023 9:25 PM, Arne Vajhøj wrote:
>>> On 6/19/2023 9:43 PM, Dave Froble wrote:
>>>> People who count for encryption to provide protection don't really care all
>>>> that much. Do enough to check the appropriate box, then not their problem.
>>>>
>>>> People who really care about security of course may use SSL, but then what
>>>> happens when the encryption is broken? The user's data is available to the
>>>> hackers. But what if the app developers insured that the data, if encryption
>>>> is defeated, doesn't really mean anything to the hackers. Some custom stuff
>>>> in addition to SSL and such. Yeah, even then, some hacker might figure out
>>>> the data. But isn't it better to make it as tough for the hacker as one can?
>>>>
>>>> Now I'll hear from some "you got to use standards". I'd ask "why?" The
>>>> problem with standards is, everybody knows them.
>>>
>>> There are two benefits from going standard.
>>>
>>> Interoperability. If the communication is based on standards, then
>>> software from different vendors can communicate. SSL (TLS 1.2 or 1.3
>>> of course!) is widely supported standard so C programs on VMS,
>>> Java programs on Linux and VB.NET programs on Windows can communicate
>>> without problems due to the standard.
>>>
>>> Security. The public known standard protocols and algorithms are being
>>> reviewed by thousands of mathematicians all over the world. A home grown
>>> protocol and algorithm will be reviewed by a few software engineers
>>> which may or may not have math/cryptography knowledge. The first will
>>> simply result in a better solution.
>>>
>>> Good cryptography does not depend on protocols or algorithms
>>> being unknown. It is possible to constructs stuff that are secure
>>> even with known protocols/algorithms. And protocols/algorithms
>>> that are not secure if known are very bad. They will eventually leak.
>>
>> You sort of missed the point of my post.
>
> I miss a lot.
>
> But I read it as that you suggested not using standard
> protocols/algorithms but something unique/homemade.
>
> Was that not the case?
>
> Arne
>
>

No!

I use such as SSL and other standards.

But then, it's not enough to say "hey, we use standards", and assume all will be
well. Perhaps going beyond such and further trying to make your data useless to
those who should not have it.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/5/2023 7:32 PM, Dave Froble wrote:
> On 7/5/2023 3:37 PM, Arne Vajhøj wrote:
>> On 7/5/2023 9:05 AM, Dave Froble wrote:
>>> On 7/4/2023 9:25 PM, Arne Vajhøj wrote:
>>>> On 6/19/2023 9:43 PM, Dave Froble wrote:
>>>>> People who count for encryption to provide protection don't really
>>>>> care all
>>>>> that much.  Do enough to check the appropriate box, then not their
>>>>> problem.
>>>>>
>>>>> People who really care about security of course may use SSL, but
>>>>> then what
>>>>> happens when the encryption is broken?  The user's data is
>>>>> available to the
>>>>> hackers.  But what if the app developers insured that the data, if
>>>>> encryption
>>>>> is defeated, doesn't really mean anything to the hackers.  Some
>>>>> custom stuff
>>>>> in addition to SSL and such.  Yeah, even then, some hacker might
>>>>> figure out
>>>>> the data.  But isn't it better to make it as tough for the hacker
>>>>> as one can?
>>>>>
>>>>> Now I'll hear from some "you got to use standards".  I'd ask
>>>>> "why?"  The
>>>>> problem with standards is, everybody knows them.
>>>>
>>>> There are two benefits from going standard.
>>>>
>>>> Interoperability. If the communication is based on standards, then
>>>> software from different vendors can communicate. SSL (TLS 1.2 or 1.3
>>>> of course!) is widely supported standard so C programs on VMS,
>>>> Java programs on Linux and VB.NET programs on Windows can communicate
>>>> without problems due to the standard.
>>>>
>>>> Security. The public known standard protocols and algorithms are being
>>>> reviewed by thousands of mathematicians all over the world. A home
>>>> grown
>>>> protocol and algorithm will be reviewed by a few software engineers
>>>> which may or may not have math/cryptography knowledge. The first will
>>>> simply result in a better solution.
>>>>
>>>> Good cryptography does not depend on protocols or algorithms
>>>> being unknown. It is possible to constructs stuff that are secure
>>>> even with known protocols/algorithms. And protocols/algorithms
>>>> that are not secure if known are very bad. They will eventually leak.
>>>
>>> You sort of missed the point of my post.
>>
>> I miss a lot.
>>
>> But I read it as that you suggested not using standard
>> protocols/algorithms but something unique/homemade.
>>
>> Was that not the case?
>
> No!
>
> I use such as SSL and other standards.
>
> But then, it's not enough to say "hey, we use standards", and assume all
> will be well.  Perhaps going beyond such and further trying to make your
> data useless to those who should not have it.

So you are suggesting a double encryption scheme. An application
specific encryption of the payload being transported encrypted by SSL.

If that application specific encryption use the same algorithms as
SSL, then it will not provide any benefits.

But using different algorithms is protecting you against a
future fatal flaw in one of the algorithm sets.

I will consider the risk of a fatal flaw in AES or RSA/ECC
to be found very small.

But if the application is controlling launch of ICBM's then it
may be warranted to add the extra layer of security.

Arne

On 7/5/2023 7:57 PM, Arne Vajhøj wrote:
> On 7/5/2023 7:32 PM, Dave Froble wrote:
>> On 7/5/2023 3:37 PM, Arne Vajhøj wrote:
>>> On 7/5/2023 9:05 AM, Dave Froble wrote:
>>>> On 7/4/2023 9:25 PM, Arne Vajhøj wrote:
>>>>> On 6/19/2023 9:43 PM, Dave Froble wrote:
>>>>>> People who count for encryption to provide protection don't really care all
>>>>>> that much. Do enough to check the appropriate box, then not their problem.
>>>>>>
>>>>>> People who really care about security of course may use SSL, but then what
>>>>>> happens when the encryption is broken? The user's data is available to the
>>>>>> hackers. But what if the app developers insured that the data, if encryption
>>>>>> is defeated, doesn't really mean anything to the hackers. Some custom stuff
>>>>>> in addition to SSL and such. Yeah, even then, some hacker might figure out
>>>>>> the data. But isn't it better to make it as tough for the hacker as one can?
>>>>>>
>>>>>> Now I'll hear from some "you got to use standards". I'd ask "why?" The
>>>>>> problem with standards is, everybody knows them.
>>>>>
>>>>> There are two benefits from going standard.
>>>>>
>>>>> Interoperability. If the communication is based on standards, then
>>>>> software from different vendors can communicate. SSL (TLS 1.2 or 1.3
>>>>> of course!) is widely supported standard so C programs on VMS,
>>>>> Java programs on Linux and VB.NET programs on Windows can communicate
>>>>> without problems due to the standard.
>>>>>
>>>>> Security. The public known standard protocols and algorithms are being
>>>>> reviewed by thousands of mathematicians all over the world. A home grown
>>>>> protocol and algorithm will be reviewed by a few software engineers
>>>>> which may or may not have math/cryptography knowledge. The first will
>>>>> simply result in a better solution.
>>>>>
>>>>> Good cryptography does not depend on protocols or algorithms
>>>>> being unknown. It is possible to constructs stuff that are secure
>>>>> even with known protocols/algorithms. And protocols/algorithms
>>>>> that are not secure if known are very bad. They will eventually leak.
>>>>
>>>> You sort of missed the point of my post.
>>>
>>> I miss a lot.
>>>
>>> But I read it as that you suggested not using standard
>>> protocols/algorithms but something unique/homemade.
>>>
>>> Was that not the case?
>>
>> No!
>>
>> I use such as SSL and other standards.
>>
>> But then, it's not enough to say "hey, we use standards", and assume all will
>> be well. Perhaps going beyond such and further trying to make your data
>> useless to those who should not have it.
>
> So you are suggesting a double encryption scheme. An application
> specific encryption of the payload being transported encrypted by SSL.
>
> If that application specific encryption use the same algorithms as
> SSL, then it will not provide any benefits.
>
> But using different algorithms is protecting you against a
> future fatal flaw in one of the algorithm sets.
>
> I will consider the risk of a fatal flaw in AES or RSA/ECC
> to be found very small.
>
> But if the application is controlling launch of ICBM's then it
> may be warranted to add the extra layer of security.
>
> Arne
>
>
>

Ok, an example:

Back when we were storing customer credit card information, we broke the number
into 2 parts, and stored each part on two different databases on two different
systems. Thus, any hacker would not get total CC data unless he know our
design. Also stored the exp data and pin in different locations. If someone
knew the design, then the data was still at risk. But much harder.

I do not advocate any particular design, and no, I was not thinking about double
encryption. Such stuff needs to be different, and not just more of the same
(encryption or whatever).

Assume a hacker will break in, then think of ways to make it harder to actually
cause harm.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/5/2023 8:30 PM, Dave Froble wrote:
> Back when we were storing customer credit card information,  we broke
> the number into 2 parts, and stored each part on two different databases
> on two different systems.  Thus, any hacker would not get total CC data
> unless he know our design.  Also stored the exp data and pin in
> different locations.  If someone knew the design, then the data was
> still at risk.  But much harder.

If the same application has access to both databases, then
I would say that the risk that if hackers (and that include
insiders) got access one then they got access to both is
pretty high. And the problem of having to figure out where
the different pieces are stored is not a hard problem
compared to various encryption schemes.

Arne

In article <u84l3q$kcjd$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 7/5/2023 4:33 PM, Arne Vajhøj wrote:
>> On 7/5/2023 2:23 PM, Simon Clubley wrote:
>>>  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.
>>
>> That is actually interesting.
>>
>> Per:
>>
>> https://www.openssl.org/docs/fips.html
>> https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
>>
>> then OpenSSL is FIPS 140-2 certified on:
>>
>> <quote>
>>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
>>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86)
>> without PAA
>>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64)
>> without PAA
>>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
>>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64)
>> without PAA
>>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
>>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA
>> (single-user mode)
>>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
>> i7(x64) with PAA
>>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
>> i7(x64) without PAA
>>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without
>> PAA
>> </quote>
>>
>> Maybe VSI want VMS on that list.
>
>But I wonder.
>
>How will VSI get FIPS 140-2 certification for VMS x86-64 if they only
>support running in VM not on physical hardware??

Virtual Machines, by definition, run most of their instructions
on the physical hardware, including in kernel mode. Running in
a VM does not preclude one from access to high-quality hardware
facilitated entropy sources a priori.

- Dan C.

In article <u84k26$k8rl$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 7/5/2023 2:23 PM, Simon Clubley wrote:
>> On 2023-07-04, Arne Vajhøj <arne@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.
>
>I don't think my preference for programming languages are particular
>relevant for whether your claims of:
>
># 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.
>
>are correct or not.
>
>> 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.
>
>Using HW/OS is definitely what is being done for new OS versions.
>
>But there is a difference from that and the old way not being
>acceptable.
>
>> 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 ?
>
>The question was not whether using HW/OS is good. I think everybody
>agrees it is.
>
>The question was whether not using HW/OS would cost VMS sales now
>due to being not compliant.

I rather thought it was whether existing customers would ditch
VMS due to their old versions not being up to snuff with the
latest best-practices. If they would, and Simon seems to
believe that they will and I believe him, then it stands to
reason that if VSI wants to retain customers it must provide a
path forward to a system that uses those best-practices, which
is what they are doing.

>It is hardly surprising that VSI is implementing new functionality
>looking forward instead of backwards.
>
>> 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.
>
>That is actually interesting.
>
>Per:
>
>https://www.openssl.org/docs/fips.html
>https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
>
>then OpenSSL is FIPS 140-2 certified on:
>
><quote>
> Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
> Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86)
>without PAA
> FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
> FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64)
>without PAA
> macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
> macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64)
>without PAA
> macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
> macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA
>(single-user mode)
> Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
>i7(x64) with PAA
> Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
>i7(x64) without PAA
> Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
> Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without PAA
></quote>
>
>Maybe VSI want VMS on that list.
>
>But that list is not the server market.
>
>>> 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.
>
>Yes.
>
>But old practices seems to match the description of what is acceptable.
>
>I actually copied the text in. You just omitted it when replying.
>
>>> 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 ?
>
>I quoted the text. You tell me what lines old OpenSSL does not match.

I don't know if the "old" OpenSSL has much to do with it; it
seems like it used some kind of system facility to get entropy.
The question then is about how one gets that entropy. Earlier,
in the same message where you quoted text from the NIST standard
you 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).
(from https://groups.google.com/g/comp.os.vms/c/01BdjALzsWQ/m/VggQH86-AQAJ)

But note that part of the NIST document that you copied and
pasted said the following:

|4. The noise source state shall be protected from adversarial
| knowledge or influence to the greatest extent possible. The
| methods used for this shall be documented, including a
| description of the (conceptual) security boundary's role in
| protecting the noise source from adversarial observation or
| influence.

And

|5. Although the noise source is not required to produce
| unbiased and independent outputs, it shall exhibit random
| behavior; i.e., the output shall not be definable by any
| known algorithmic rule. Documentation shall indicate
| whether the noise source produces IID data or non-IID
| data. This claim will be used in determining the test path
| followed during validation. If the submitter makes an IID
| claim, documentation shall include rationale for the claim.

Given how the `SYS$GETJPIW` interface is defined at e.g.,
https://wiki.vmssoftware.com/$GETJPI, I don't know why anyone
would believe it meets these criteria. In particular, pretty
much everything that can be returned from GETJPI is discoverable
outside of the process, violating the "shall be protected from
adversarial knowledge to the greatest extent possible" criteria
in (4), and most of it is also "definable by known algorithmic
rules", as prohibited by (5).

Furthermore, none of the documentaton criteria specified by NIST
seem to be fulfilled.

>>> 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 ?
>
>If VSI believe they need FIPS certification and that they need the new
>better entropy to get that, then it all makes sense.
>
>But if you check the list above then FIPS certification does not
>seem to be a requirements to sell servers today.

Sure. But if you have customers that you value that are making
noise about moving from your platform because of issues like
this, and you want to retain those customers, then, well, you
probably address issues like this.

On 7/5/2023 9:43 PM, Dan Cross wrote:
> In article <u84l3q$kcjd$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 7/5/2023 4:33 PM, Arne Vajhøj wrote:
>>> Per:
>>>
>>> https://www.openssl.org/docs/fips.html
>>> https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
>>>
>>> then OpenSSL is FIPS 140-2 certified on:
>>>
>>> <quote>
>>>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
>>>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86)
>>> without PAA
>>>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>>>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64)
>>> without PAA
>>>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
>>>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64)
>>> without PAA
>>>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
>>>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA
>>> (single-user mode)
>>>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
>>> i7(x64) with PAA
>>>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel
>>> i7(x64) without PAA
>>>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>>>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without
>>> PAA
>>> </quote>
>>>
>>> Maybe VSI want VMS on that list.
>>
>> But I wonder.
>>
>> How will VSI get FIPS 140-2 certification for VMS x86-64 if they only
>> support running in VM not on physical hardware??
>
> Virtual Machines, by definition, run most of their instructions
> on the physical hardware, including in kernel mode. Running in
> a VM does not preclude one from access to high-quality hardware
> facilitated entropy sources a priori.

No. But that is not the problem.

FIPS 140-2 certification is a certification of hardware
and software.

VMS 9.2-1 on a VirtualBox VM setup as ... running on
RockyLinux 9 running on Dell Inspiron 7591 with Intel i7(x64)????

Arne