I know that YMMV, but have there been any studies done on the
performance benefits of using protected keys with a crypto-express 3 vs.
secure keys?
--
Mark Jacobs
Time Customer Service
Tampa, FL
The Doctor: You know when grown-ups tell you everything's going to be
fine, and you think they
Mark,
I remember seeing a paper on the performance. It was about 30% slower than
clear key using CPACF. But still ran circles around secure key.
It avoids the entire path to the CEX cards.
Rob Schramm
Senior Systems Consultant
Imperium Group
On Thu, Jul 5, 2012 at 2:25 PM, Mark Jacobs wrote
Ooops.. I thought it was IBM. PKWARE gave a presentation on it.
http://www.share.org/p/do/sd/topic=73&sid=1067
Rob Schramm
Senior Systems Consultant
Imperium Group
On Thu, Jul 5, 2012 at 3:07 PM, Rob Schramm wrote:
> Mark,
>
> I remember seeing a paper on the performance. It was about 30%
W dniu 2012-07-05 20:25, Mark Jacobs pisze:
> I know that YMMV, but have there been any studies done on the
> performance benefits of using protected keys with a crypto-express 3 vs.
> secure keys?
>
Protected key means CPACF in use, secure key means CryptoExpress card.
The difference can be 1000
R.S. wrote:
>Protected key means CPACF in use, secure key means CryptoExpress card.
>The difference can be 1000 times or 10 times. Of course CPACF is always
>faster.
>The more cpu-intensive algorithm and the smaller block of data to be
>encrypted, the bigger difference is.
I think the second sent
riginal Message
From: Phil Smith
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Fri, July 6, 2012 3:32:01 PM
Subject: Re: Secure Encryption Keys vs Protected Keys
R.S. wrote:
>Protected key means CPACF in use, secure key means CryptoExpress card.
>The difference can be 1000 times or 10 times. Of
Lloyd Fuller wrote:
>This statement implies that CPACF REQUIRES ICSF. That is NOT true. You can
>happily do CPACF operations yourself without ICSF even configured on the
>system. IBM's white papers about CPACF performance indicate that ICSF imposes
>a
>big performance hit on CPACF.
*blush* You
W dniu 2012-07-06 21:49, Lloyd Fuller pisze:
>> Consider the cost of a CEX operation as ((ICSF call CPU)+I/O) and the cost
>> of a
>> CPACF operation as ((ICSF call)+(some >CPU cycles for the operation)). So
>> the
>> difference is I/O vs. CPACF cycles. The I/O cost doesn't change (much) wit
I think there may be some confusion regarding "protected".
Perhaps OA29193 will shed some light on the High Performance ICSF Secure
key.
ftp://ftp.software.ibm.com/s390/zos/racf/pdf/oa29193.pdf
Of course routines coded to directly exploit CPACF are pretty much always
going to run circles around
I'll point you to the IBM Crypto performance whitepapers, available at
www.ibm.com/systems/z/advantages/security/z10cryptography.html. (Look on the
right under 'Learn More' for your machine type.) The numbers are very ivory
tower, and your mileage will vary, however, you can use these numbers
Replying again to finish the last sentence!
I'll point you to the IBM Crypto performance whitepapers, available at
www.ibm.com/systems/z/advantages/security/z10cryptography.html. (Look on the
right under 'Learn More' for your machine type.) The numbers are very ivory
tower, and your mileage
Greg Boyd's contribution was a welcome one.
I have two comments about it.
First, the performance white papers are 'ivory tower' only in the
sense that their tone is formal and academic; their substance is
severely practical.
Second, the point that large block sizes are better than small ones
has
ftrag
von Greg Boyd
Gesendet: Sonntag, 8. Juli 2012 22:54
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Secure Encryption Keys vs Protected Keys
Replying again to finish the last sentence!
I'll point you to the IBM Crypto performance whitepapers, available at
www.ibm.com/systems/z/adva
David Stokes wrote:
>As I understand it CPACF is basically some hardware instructions you can
>invoke from assembler code (I've been using AES128 and SHA1 for our
>inter-system communication software for quite some time). CEXx is a subsystem
>which can only be accessed via various APIs (ICSF).
David Stokes wrote
CEX otoh is accessed via a queuing mechanism. It is asynchronous and
suspends the executing work unit until the crypto-operation is
complete (along with encrypting and decrypting keys etc).
In its standard use the word 'asynchronous' and the behavior he
describes are incompat
Sorry to hear you didn't get the special briefing, John.
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von John Gilmore
Gesendet: Montag, 9. Juli 2012 15:28
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Secure Encryption Ke
John Gilmore wrote:
>In its standard use the word 'asynchronous' and the behavior he
>describes are incompatible. Did he perhaps mean 'synchronous'
>instead?
>Or is he using the word 'asynchronous' in a private, arcane sense? If
>so, he needs to explain that very special sense.
I took it to mea
Phil Smith wrote:
"Yes, Protected Key requires ICSF and a CEX."
Should that not read "Yes, Secure Key requires ICSF and a CEX."?
Blatant plagiarism follows from my copy of the z196 Tech Guide, Section
6.2.2 'CPACF Protected key':
"The zEnterprise CPCs support the protected key implementati
Nope.
It is correct. As is your statement.
The "key" (no pun intended) is that the protected key scheme is dependent
on having secure keys to start with.
Rob Schramm
Senior Systems Consultant
Imperium Group
On Mon, Jul 9, 2012 at 10:21 AM, Tom Ambros wrote:
> Phil Smith wrote:
>
> "Yes, Pro
Greg,
I can't tell.. was that a correction or clarification?
Rob Schramm
Senior Systems Consultant
Imperium Group
On Mon, Jul 9, 2012 at 10:29 AM, Rob Schramm wrote:
> Nope.
>
> It is correct. As is your statement.
>
> The "key" (no pun intended) is that the protected key scheme is dependen
Montag, 9. Juli 2012 16:22
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Secure Encryption Keys vs Protected Keys
Phil Smith wrote:
"Yes, Protected Key requires ICSF and a CEX."
Should that not read "Yes, Secure Key requires ICSF and a CEX."?
Blatant plagiarism follows from
ortant enough to comment on before.
>
> -Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Tom Ambros
> Gesendet: Montag, 9. Juli 2012 16:22
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Secure Encryption Keys vs P
ist [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von Rob Schramm
Gesendet: Montag, 9. Juli 2012 18:13
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Secure Encryption Keys vs Protected Keys
How is the key generated?
Rob Schramm
Senior Systems Consultant
Imperium Group
On Mon, Jul 9, 2012 at 12:07 PM,
achricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Rob Schramm
> Gesendet: Montag, 9. Juli 2012 18:13
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Secure Encryption Keys vs Protected Keys
>
> How is the key generated?
>
>
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von Rob Schramm
Gesendet: Montag, 9. Juli 2012 19:07
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Secure Encryption Keys vs Protected Keys
Not that key. The key that will be stored under the "wrapping" key.
Rob
--Ursprüngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im
> Auftrag von Rob Schramm
> Gesendet: Montag, 9. Juli 2012 19:07
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Secure Encryption Keys vs Protected Keys
>
> Not that key. Th
Rob Schramm wrote:
>Yep.
>By using ICSF plus CEX, and using protected key.. you get more of the
>performance characteristics of CPACF but retain the more secure nature of
>secure key.
>Yes the exposure is less.. but it will always be suspect. Ultimately, the
>protected key is dependent on the "s
Yep.
But in the case of "cat herding" requirements, less exposure is always a
better idea. The "best" idea would be to be secure.
Considering the cost, it is relatively inexpensive to buy a CEX feature for
the "priceless" piece of mind of being secure. Even if you add in the cost
of a TKE or DK
Effectively, you need both ICSF and a CEX3 to take advantage of Protected Keys.
As was pointed out in another append, you can use the PCKMO instruction to wrap
a key. That is, you would take a clear key and wrap it, creating a protected
key. And as was also pointed out in that post, I'm not su
expense of CEX hardware.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Greg Boyd
Sent: Monday, July 09, 2012 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Secure Encryption Keys vs Protected Keys
Effectively, you need both
curity for the clear key without the expense
> of CEX hardware.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Greg Boyd
> Sent: Monday, July 09, 2012 4:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
>
On Mon, 9 Jul 2012 16:49:15 -0400, Rob Schramm wrote:
>... because security through obscurity always works.
lol - I think this discussion just about lost interest for me when Greg posted
thus:
Since a protected key begins life as a secure key, the operational key must
first be decrypted from
Shane Ginnane wrote:
>lol - I think this discussion just about lost interest for me when Greg posted
>thus:
>
>Since a protected key begins life as a secure key, the operational key must
>first be decrypted from under the master key (inside the CEX3) but then it is
>wrapped using the wrapping ke
Well, it made sense to me :-)
But I understand the confusion. There are so many terms with slightly
different meanings: clear key, secure key, protected key, wrapped key,
wrapping key, public key, private key, master key, operational key. It's not
just the math that's complicated! I guess i
This makes you the keymaster, right?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Only when Gozer the Gozerian is involved. Which might actually be a
requirement in a master key ceremony for TKE... of course it is completely
configurable... but I am not sure there is a demi-god role.
I know my first couple of times trying to wrap my head around the roles for
the TKE workstati
>Shane, just curious - why?
I will defer to Gregs subsequent response which pretty-well hit it on the head.
I spin through my mail first thing in the morning. And for us in Aus that
usually means after threads have had time to "ripen" somewhat overnight.
Often that means "run off track", but in
I just discovered this discussion group, and I thought I'd add a little bit of
information to the discussion. I am a lead architect in development of the IBM
crypto coprocessors (Crypto Express, etc), and in design of the CCA
architecture and its verbs. I also happen to have been deeply involv
Thanks, Phil.
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von Phil Smith
Gesendet: Montag, 9. Juli 2012 15:11
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Secure Encryption Keys vs Protected Keys
David Stokes wrote:
>A
39 matches
Mail list logo
