: Technical Reason? - Why you can't encrypt load
libraries (PDSE format)?
Radoslaw Skorupka wrote, in part:
>"security by obscurity" means just the key under the mat.
I'd agree that it perhaps SHOULD mean that, but that isn't how people
Radoslaw Skorupka wrote, in part:
>"security by obscurity" means just the key under the mat.
I'd agree that it perhaps SHOULD mean that, but that isn't how people use the
term. And even then, I'd submit that that's just another trivial case of "if
you have enough": you have to know/think to
Gentlemen,
Let me chime in
Password are to be kept secret. Encryption keys (except public ones) are
to be kept secret.
This is widely known and quite obvious IMHO.
Lost/disclosed password is more or less like lost door key. (Assuming no
MFA, where the password is only one of several "keys").
Paul Gilmartin wrote:
>I believe otherwise. I know of a case where a vendor allowed a product
>to escape to the field containing a tester's back door, and another
>related to II14489. Either could be exploited with no brute force,
>merely knowledge of the existence and nature of the defect. In the
On Tue, 16 Jan 2024 12:31:36 -0500, Phil Smith III wrote:
>...
>For example, 256-bit AES can be broken by brute force-if you have until the
>end of time. (And if you'll know it when you see it, another issue.) But that
>"until the end of time" means you can use it to outrun the bear.
>
Leonard D Woren wrote, in part:
>Software can be hacked.
Um. And? What's your point? Anything can be hacked:
https://xkcd.com/538/
The phrase "security by obscurity" has bothered me for years. It's *ALL*
security by obscurity. If you have enough "stuff"-time, money, guns
(wrenches)-you can get
Radoslaw Skorupka wrote
> Note: Dataset Encryption (DSE) is *not* a replacement for RACF or other
> security system.
> It is a solution to keep data secret even if you have (unintended) access to
> the dataset. Bad RACF authority? NO!
> It could be administrative access via STGADMIN, shared
W dniu 16.01.2024 o 03:13, Michael Stein pisze:
On Mon, Jan 15, 2024 at 02:41:45PM -0600, Walt Farrell wrote:
On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman wrote:
For encryption, the analogous method might be: Once a jobstep has
Opened an encrypted data set to read it, they cannot write
ent people to all agree to act nefariously.
Eric Rossman
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Leonard D Woren
Sent: Monday, January 15, 2024 9:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Technical Reason? - Why you can't encrypt load
libraries
OK. So we've established that the key is set via software.
Software can be hacked.
And now there's only a single spit of data to focus all the effort
on. Years ago at a SHARE presentation, I caught an IBMer after the
session and they admitted that I was correct.
/Leonard
P.S. Someone
On Mon, Jan 15, 2024 at 02:41:45PM -0600, Walt Farrell wrote:
> On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman
> wrote:
> For encryption, the analogous method might be: Once a jobstep has
> Opened an encrypted data set to read it, they cannot write to, nor Open,
> an unencrypted output data
In CICS one can have encrypted and non-encrypted files open
simultaneously.
This is kind of a MUAS, Multiple User Address Space.
I was going to mention the problem of Connect:Direct but let it
go. But since the CICS thing was also brought up
C:D has similar issues to CICS where it can
On Mon, 15 Jan 2024 14:45:06 -0600, Joe Monk wrote:
>How would that be practical? How would you, for instance, do a batch update
>to an encrypted dataset from a CICS vsam file?
Sorry; I don't understand the question. How do you do it today?
--
Walt
How would that be practical? How would you, for instance, do a batch update
to an encrypted dataset from a CICS vsam file?
Joe
On Mon, Jan 15, 2024 at 2:42 PM Walt Farrell wrote:
> On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman
> wrote:
>
> >Answering a number of comments in order, in one
On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman wrote:
>Answering a number of comments in order, in one message.
>
>First: I don't think being able to encrypt load libraries is worth it.
>Encrypted executables, in general, are not going to increase security.
>
>Jousma, David:
>
>>
Answering a number of comments in order, in one message.
First: I don't think being able to encrypt load libraries is worth it.
Encrypted executables, in general, are not going to increase security.
Jousma, David:
> Encrypt everything with the same HLQ, with the same key
> that's a big
W dniu 15.01.2024 o 05:16, Phil Smith III pisze:
Steve Estle wrote, in part:
but we'd like to encrypt as much as possible in our environment
Why? What problem are you trying to solve? Remember that DSE provides
protection against exactly two attacks:
1) Someone getting at the wire between
SE | MD RSCB2H | Grand
Rapids, MI 49546
616.653.8429
From: IBM Mainframe Discussion List on
behalf of Leonard D Woren
Sent: Sunday, January 14, 2024 7:05:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load librar
edu>
Sent: Saturday, January 13, 2024 12:06 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
I can imagine technical reason to not encrypt such libraries.
However encryption is a kind of data protection. Data. Not pr
While I strongly believe there is a technical reason behind, it is NOT
the one described below.
Both PDSE and basic PS can be encrypted.
The requirement: SMS-managed.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 14.01.2024 o 06:50, Attila Fogarasi pisze:
It is indeed a technical reason: PDS
on behalf of
Rick Troth
Sent: Monday, January 15, 2024 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
On 1/13/24 11:28, Steve Estle wrote:
> I know this seems innocuous, but we'd like to encrypt as much as possi
On 1/14/24 01:07, Phil Smith III wrote:
aul Gilmartin asked:
What about Format preserving encryption?
Format-Preserving Encryption is for structured data, i.e., specific fields. You
would not use it on a binary blob; at that point, you'd use XTS or one of the
other AES modes whose
On 1/13/24 11:28, Steve Estle wrote:
I know this seems innocuous, but we'd like to encrypt as much as possible in
our environment ...
Forgive my tone, Steve. And please don't take this as directed at you,
but at the broader industry, especially at "seatback magazine management".
Many
On Behalf Of
Leonard D Woren
Sent: 15 January 2024 01:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
There has to be a way to set it via software. What happens when you replace
the machine including the hardware where the master
Steve Estle wrote, in part:
>but we'd like to encrypt as much as possible in our environment
Why? What problem are you trying to solve? Remember that DSE provides
protection against exactly two attacks:
1) Someone getting at the wire between the array and the CEC
2) Rogue storage admin
On 1/14/2024 5:52 PM, Leonard D Woren wrote:
There has to be a way to set it via software. What happens when you
replace the machine including the hardware where the master key is
stored?
How is the key set into the disaster recovery machine?
In our case, we brought z/OS up on the DR
Sent: Sunday, January 14, 2024 7:05:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
(I read the whole thread before starting this reply. ) Steve Estle wrote on 1/13/2024 8:
28 AM: > [. . . ] > My true reason for com
Discussion List on behalf of
Leonard D Woren
Sent: Sunday, January 14, 2024 7:05:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
(I read the whole thread before starting this reply. ) Steve Estle wrote on
1/13/2024 8: 28 AM
(I read the whole thread before starting this reply.)
Steve Estle wrote on 1/13/2024 8:28 AM:
[...]
My true reason for composing this is that we've discovered the inability to
encrypt load libraries - even in PDSE format.
[...]
I know this seems innocuous, but we'd like to encrypt as much as
_
From: IBM Mainframe Discussion List on behalf
of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, January 13, 2024 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries
(PDSE format)?
On Sat, 13 Jan
The technical reason "why" is because it would be very difficult to do, would
have adverse performance effects for the system, and there is not at this point
a business case for providing it. So you're not going to get it just because
you think it sounds nice (and even because it sounds
On 1/14/2024 7:05 AM, Jousma, David wrote:
The technology that I see as beneficial is one that I think is in the works
with ibm in that data will never be decrypted including during execution. I
forget the term used for that.
Homomorphic encryption, but that has limited use.
--
Phoenix
@LISTSERV.UA.EDU
Subject: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Everyone, Our team is knee deep into pervasive encryption rollout on ZOS 2. 5
and despite the fact such functionality has been out for years by IBM to do
this, it is quite surprising how many
-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
John von Neumann, call your office.
On Sat, Jan 13, 2024 at 5:41 PM Seymour J Metz wrote:
> Programs are data.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.ed
___
> From: IBM Mainframe Discussion List on behalf
> of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
> Sent: Saturday, January 13, 2024 12:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Technical Reason? - Why you can't encrypt load librar
On 1/13/2024 9:50 PM, Attila Fogarasi wrote:
It is indeed a technical reason: PDS and PDSE datasets cannot be
Extended-Format. Pervasive Encryption requires Extended-Format. The
restrictions on Extended-Format have been problematic for the past decade,
so presumably not easy to fix. A few
uary 13, 2024 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Technical Reason? - Why you can't encrypt load libraries
> (PDSE format)?
>
> On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote:
>
> >I can imagine technical reason to not encrypt such libraries.
&
Interesting discussion. Some thoughts.
First, it's not "Pervasive Encryption" you're talking about. It's IBM z/OS data
set encryption (DSE). PE is the IBM encryption strategy. When data set
encryption came along, IBM kept calling it PE, but it's just part of PE (the
rest of which hasn't
; > From: IBM Mainframe Discussion List on behalf
> > of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
> > Sent: Saturday, January 13, 2024 9:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Technical Reason? - Why you can't encrypt load librari
Is the problem that they cannot be encrypted or that they cannot be executed
when in encrypted format?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
It is indeed a technical reason: PDS and PDSE datasets cannot be
Extended-Format. Pervasive Encryption requires Extended-Format. The
restrictions on Extended-Format have been problematic for the past decade,
so presumably not easy to fix. A few other dataset types are also affected
(such as
://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Tony Harminc
Sent: Saturday, January 13, 2024 11:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't
; נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
> From: IBM Mainframe Discussion List on behalf
> of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
> Sent: Saturday, January 13, 2024 9:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Technica
UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote:
>
>The issue on STEPLIB is simply that IBM doesn't see a business case to support
>it. Part of that support would be an update to APF and
On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote:
>
>The issue on STEPLIB is simply that IBM doesn't see a business case to support
>it. Part of that support would be an update to APF and program control for
>paths. Would you want individual executables in STEPLIB, or only directories?
From: IBM Mainframe Discussion List on behalf of
Steve Estle
Sent: Saturday, January 13, 2024 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Everyone,
Our team is knee deep into pervasive encryption rollout on ZOS 2.5
;
Sent: Saturday, January 13, 2024 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE
format)?
I can imagine technical reason to not encrypt such libraries.
However encryption is a kind of data protection. Data. Not programs.
--
Ra
יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, January 13, 2024 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encryp
IBM/MS-DOS 6 stored compressed programs by having a decompression stub and
the compressed program as the remainder of the file data.
On Sat, Jan 13, 2024 at 1:50 PM Grant Taylor <
023065957af1-dmarc-requ...@listserv.ua.edu> wrote:
> On 1/13/24 13:39, Gibney, Dave wrote:
> > It should be
On 1/13/24 13:39, Gibney, Dave wrote:
It should be obvious, but as a practical matter, you can't encrypt
the modules that do the decryption and it also follows that you can't
encrypt the modules that provide the execution environment (z/OS)
for these modules.
I would like to agree with you.
It should be obvious, but as a practical matter, you can't encrypt the modules
that do the decryption and it also follows that you can't encrypt the modules
that provide the execution environment (z/OS) for these modules.
--
On 1/13/24 11:06, Radoslaw Skorupka wrote:
However encryption is a kind of data protection.
Conversely encryption is a kind of data authentication / verification.
Data. Not programs.
Programs are special data used to manipulate / act on other data.
--
Grant. . . .
On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote:
>I can imagine technical reason to not encrypt such libraries.
>However encryption is a kind of data protection. Data. Not programs.
>
But some load modules/program objects aren't really files. As Ifond
out to my dismay as a novice
1.
Restrictions for encrypted data sets
-
System data sets (such as Catalogs, SMS control data sets, SHCDS, HSM
data sets) must not be encrypted, unless otherwise specified in
product documentation.
-
Data sets used during IPL must not be encrypted.
Page
I can imagine technical reason to not encrypt such libraries.
However encryption is a kind of data protection. Data. Not programs.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 13.01.2024 o 17:28, Steve Estle pisze:
Everyone,
Our team is knee deep into pervasive encryption rollout on ZOS 2.5
Everyone,
Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and despite
the fact such functionality has been out for years by IBM to do this, it is
quite surprising how many software vendors when you contact them they have no
clue what you're talking about - that is a complete
56 matches
Mail list logo
