Phil Smith III wrote:
>Timothy Sipples disagrees, which is his right,
>but the industry doesn't, so I'm not sure what
>else to say here.
To recap, you claimed this:
>Read about data-centric protection, note the analysts and
>standards bodies saying that container-level protection is
>just not
15 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Friday, 9 August 2019 01:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?
Ron Hawkins wrote:
>That would be an improvement over a
Timothy Sipples disagrees, which is his right, but the industry doesn't, so I'm
not sure what else to say here.
.phsiii
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Ron Hawkins wrote:
>That would be an improvement over a random cypher, but wouldn't the length
>and repeatability of the data patterns after encryption negatively affect
>LZW compression, along with deduplication?
Not sure I understand your question, but I'll try.
Length-is unchanged
971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Phil Smith III
Sent: Tuesday, 6 August 2019 23:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?
Ron Hawkins wrote:
>One a
Phil Smith III wrote:
>I think you're missing one of my main points: "Substantial,
>real progress" isn't what data set encryption provides. It
>provides a LITTLE BIT of protection for a FEW minor attack
>vectors.
I disagree.
>Read about data-centric protection, note the analysts and
>standards
Timothy Sipples wrote:
>Even if you believe IBM caused some confusion -- I cannot find much
>evidence in the historical record of official IBM communications, but if
>that's what you believe -- that's certainly NOT a reason to add any more.
>I've asked you to help reduce terminology confusion,
Correcting a couple of careless "n" and "m" typos in my previous post...
--
Another, similar approach that is sometimes used is to use "key shares" instead
of components. The difference is that with components, you must combine ALL of
the components to form the master key, but
The master keys, which are stored securely inside the Crypto Express HSM and
can never be extracted, are the top-level keys in the key hierarchy. Your
application-level keys are stored outside the HSM, encrypted by the master
keys. Thus, if the HSM fails, you still have the externally-stored
At $previousjob we had copies of the ICSF Master Encryption Keys stored in
secure locations. During disaster recovery testing authorized people would
re-enter those keys into the crypto-express hardware on that processor. One
time we also lost a crypto-express card on our production machine.
Phil Smith III wrote:
>I feel that IBM inadvertently caused the confusion by calling
>the data set encryption "PE" at first: the fact that this
>thread refers to it as such actually supports that, no?
You've made this assertion a couple times now, and it's not actually true
as far as I can tell.
On 6 Aug 2019 07:59:59 -0700, in bit.listserv.ibm-main
(Message-ID:)
lenni...@rsmpartners.com (Lennie Dymoke-Bradshaw) wrote:
Access to the ICSF CKDS would not be enough, as the keys
held there are encrypted (wrapped) using the master key.
The master key is held in the Crypto Express domain
Paul Gilmartin wrote, re FPE being ASCII-EBCDIC transparent:
>I'm astonished that's possible (but it can't be proven impossible). Suppose I
>change
>x'C1' to x'41' in the clear text (in fact, only a single bit change). With
>strong encryption
>that must change numerous bits in the encrypted
On Tue, 6 Aug 2019 00:42:48 -0400, Phil Smith III wrote:
>
>...; but more significantly, consider normal data flows: data moves between
>ASCII and EBCDIC worlds, gets translated in the process. With whole-file,
>non-format-preserving encryption, that means you have to decrypt, translate,
Joel C. Ewing pointed out that FPEd data won't compress quite as well as
un-FPEd since repeated characters will not be repeated in the ciphertext. This
is no doubt true, although some number of random repeats will occur in the
ciphertext as well.
He wrote:
>Unless by format-preserving data
On 8/6/19 8:38 AM, Phil Smith III wrote:
> Ron Hawkins wrote:
>
>> One area where PE encryption, as implemented on z is where it is used
>> together with compression.
>
>
>> The horse must go in front of the cart, meaning compression must happen
>> before encryption, because it will be
: www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Andrew Rowley
Sent: 06 August 2019 12:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?
On 5/08/2019 3:08 pm
Timothy Sipples
>Phil, I don't think your assertion is true, but, regardless, what's the
>problem with granting another vendor the courtesy of referring to its
>products and offerings by the names they give them? If you're referring to
>z/OS Data Set Encryption, then use the name z/OS Data
Ron Hawkins wrote:
>One area where PE encryption, as implemented on z is where it is used
>together with compression.
>The horse must go in front of the cart, meaning compression must happen
>before encryption, because it will be ineffective if you do it after.
Not true with
On 5/08/2019 3:08 pm, Timothy Sipples wrote:
Lennie Dymoke-Bradshaw wrote:
My first reason for PE for data sets is that encryption
protects the data when it is accessed outside of its normal
environment (i.e. not via the data's normal RACF
environment).
Some other examples, in no particular
Phil Smith III wrote:
>(Note that Im using the Pervasive Encryption term
>in the sense that IBM did when it was first introduced:
>the whole-data set encryption on z/OS. More recently
>theyve expanded it to mean the entire IBM encryption
>strategy, which is still developing and not
2019 04:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?
ITschak Mugzach wrote:
>PE is much cheaper, CPU wise, than a field level encryption as it use
>bulk
>encryption. encrypting field by field is much more expensive and affect
>el
Lennie Dymoke-Bradshaw wrote, re platform-specificity:
>Why do you think this is platform specific? The AES encryption keys
>involved can be managed by an external key manager, (such as EKMF) and
>so those keys can be securely deployed to other (secured) platforms. The
>encrypted data can be
III
Sent: 05 August 2019 17:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Pervasive Encryption - why?
Cameron Conacher asked about the value of PE, and various folks provided good
answers. (Note that I'm using the "Pervasive Encryption" term in the sense that
IBM di
ITschak Mugzach wrote:
>PE is much cheaper, CPU wise, than a field level encryption as it use bulk
>encryption. encrypting field by field is much more expensive and affect
>elapse as well.
Of course. That's part of the attraction. Yes, field-level is more expensive.
It's also more secure.
Phil,
PE is much cheaper, CPU wise, than a field level encryption as it use bulk
encryption. encrypting field by field is much more expensive and affect
elapse as well.
I believe that what IBM is doing is to make the mainframe a file server.
and this is the correct way to use the data. Don't
Cameron Conacher asked about the value of PE, and various folks provided good
answers. (Note that Im using the Pervasive Encryption term in the sense that
IBM did when it was first introduced: the whole-data set encryption on z/OS.
More recently theyve expanded it to mean the entire IBM
Lennie Dymoke-Bradshaw wrote:
>My first reason for PE for data sets is that encryption
>protects the data when it is accessed outside of its normal
>environment (i.e. not via the data's normal RACF
>environment).
Some other examples, in no particular order: anything IPL'ed on the system
(or that
Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
ITschak Mugzach
Sent: Sunday, August 4, 2019 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Pervasive Encryption - why?
And the major reason, it easy
List On Behalf
> Of Cameron Conacher
> Sent: 03 August 2019 17:49
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Pervasive Encryption - why?
>
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF,
Web: www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Cameron Conacher
Sent: 03 August 2019 17:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Pervasive Encryption - why?
H
IN@LISTSERV.UA.EDU
> Subject: Pervasive Encryption - why?
>
> Hello everyone,
> I have a curiousity question about Pervasive Encryption.
> If we are already protecting resources with RACF, what additional benefit
> do we get from Pervasive Encryption? I think it is a good ide
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Cameron Conacher
Sent: Saturday, August 3, 2019 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Pervasive Encryption - why?
Hello everyone,
I have a curiousity question about Pervasive Encryption.
If we are already
There are some good presentations on SHARE about this. The point about
backups is that the backups are made of the encrypted file, by personnel
and software that do *not* have the access to the decryption key. That
allows admins & sysprogs to manage storage & such without having the
ability to
On Behalf Of
Matt Hogstrom
Sent: Saturday, August 3, 2019 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Pervasive Encryption - why?
One use case is backups. If someone can access a backup outside of the
controls the system it resides on employs they could not compromise the data
Hello Matt,
I am not sure about backups.
This is Pervasive Encryption.
So, again my understanding is that IF your RACFID can access the file, you
will read the data and it will be presented to you as unencrypted.
Now, if you write it to DASD and encryption is on for that device it will
be
On Sat, 3 Aug 2019 13:24:46 -0400, Matt Hogstrom wrote:
>One use case is backups. If someone can access a backup outside of the
>controls the system it resides on employs they could not compromise the data.
>Consider potential data services that host backups offsite for instance. Your
One use case is backups. If someone can access a backup outside of the
controls the system it resides on employs they could not compromise the data.
Consider potential data services that host backups offsite for instance. Your
protecting your data while entrusting someone with ensuring its
Hello everyone,
I have a curiousity question about Pervasive Encryption.
If we are already protecting resources with RACF, what additional benefit
do we get from Pervasive Encryption? I think it is a good idea, since
encrypted data lets me sleep better. Pervasive Encryption appears to be
very
39 matches
Mail list logo
