Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Todd Arnold]

Right - the CPACF Protected Keys are *very* secure and we were very happy with 
our ability to add that feature.  Unfortunately, for some applications (such as 
payment card systems), the standards require a "Secure Cryptographic Device" 
(SCD) like an HSM that has advanced active tamper detection and response - so 
you have no choice in those cases.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Greg Dyck]

On 6/19/2017 8:00 AM, Todd Arnold wrote:

- If you need "secure keys" - keys that are protected by hardware that
cannot be subverted, even by the highest-technology methods - then
use CEX.  (but if you need a lower level of security, consider CPACF
Protected Key mode.)


I would note that CPACF protected keys are *very* secure, as they are 
good only on the system that generates them for the life of that IPL. 
While not impregnable like secure keys, they usually end up on the plus 
side of scales when you consider the possibility of breaking the 
encryption of a CPACF encrypted key vs the significant reduction in 
elapsed time over the CEX when processing large amounts of data.


ICSF *can* convert a secure key to a CPACF protected key for use by the 
cipher instructions if the appropriate options and security profiles are 
established.


Regards,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Tony Thigpen]

The "Encryption Facility for z/VSE" product is used to transport data 
between VSE and z/OS or other platform that would accept data encrypted 
by ""Encryption Facility for z/OS".


It does *not* support "data at rest". It does allow you to copy and 
encrypt a file, but the whole file has to be decrypted and restored 
before it can be used by the system. That is not "data at rest"


There is only one "data at rest" product for VSE. Dino/Protect.

I developed Dino/Protect back in 2007. http://www.dinoprotect.com

But, here is the real crux of the matter. While I sold about a dozen 
copies of the back-up encryption piece, nobody in the VSE community 
though "data at rest" was needed. All they want is encrypted backups. 
And, since then, encrypted tape drives have been developed by IBM so 
everybody is going that route.


So, it's available, but nobody came to the party.

For those that are wondering about the key, the root for the key is a 
random string somewhere in the middle of the software. The root is 
manipulated, then ORed, then encrypted, then manipulated again prior to 
actually being used as the key to call CPACF. (The manipulation and 
encryption is also done by the CPACF.) And, while it's just 128 AES, I 
could easily support any key length supported by CPACF.


The software even supports encrypting just specific fields, of any 
length, within the record. It also has program controls so that an 
IDCAMS EXPORT does not decrypt the data during backups.


But, again, nobody came to the party. :-(

Tony Thigpen

Joerg Schmidbauer wrote on 06/19/2017 09:22 AM:

Todd pointed me to this topic, because it's a z/VSE related question, not z/OS.

From my point of view Tony and Todd explained everything correctly.

Just one additional info:
There is an optional feature "Encryption Facility for z/VSE" that allows 
encrypting
data at rest (Librarian members, VSAM files, backup tapes, real tapes and 
vtapes).
It's functionality and usage is described in the z/VSE Administration Guide:
https://www.ibm.com/systems/z/os/zvse/documentation/#vse
It uses CPACF and crypto cards transparently. CPACF is used for encrypting the
data. A crypto card is needed only when using public-key encryption (refer to 
the book)
with an RSA key greater than 1024 bits. The other option is "password-based"
encryption, where the symmetric key gets derived from a password/passphrase.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Joerg Schmidbauer]

Todd pointed me to this topic, because it's a z/VSE related question, not z/OS. 
From my point of view Tony and Todd explained everything correctly. 
Just one additional info:
There is an optional feature "Encryption Facility for z/VSE" that allows 
encrypting
data at rest (Librarian members, VSAM files, backup tapes, real tapes and 
vtapes).
It's functionality and usage is described in the z/VSE Administration Guide:
https://www.ibm.com/systems/z/os/zvse/documentation/#vse
It uses CPACF and crypto cards transparently. CPACF is used for encrypting the
data. A crypto card is needed only when using public-key encryption (refer to 
the book)
with an RSA key greater than 1024 bits. The other option is "password-based"
encryption, where the symmetric key gets derived from a password/passphrase.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Todd Arnold]

So, the discussion about ICSF is not meaningful - ICSF runs on z/OS, and you're 
not using z/OS in this case.

In general, the choice between CPACF and CEX is fairly straightforward.

- If the function(s) you need can be done with CPACF, then use CPACF.  
   It is faster than CEX for everything it does, but it can only do a small 
   number of things.

- If you need "secure keys" - keys that are protected by hardware that 
   cannot be subverted, even by the highest-technology methods - then 
   use CEX.  (but if you need a lower level of security, consider CPACF 
   Protected Key mode.)

- If you need the functions that are available only on CEX, then use CEX.  
   Some typical examples are public-key cryptography (CPACF only does
   symmetric key crypto and hashing) and the wide array of specialized 
   functions required in banking and payment card systems.

Sometimes, this means using both CEX and CPACF.  SSL/TLS is a good example - 
this is typically done by using CEX for the public-key operations involved in 
setting up the session, then using CPACF for the symmetric-key operations used 
to encrypt/decrypt the session traffic.  Often, the SSL/TLS software is 
designed to do this automatically.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Greg Boyd]

I'm a little late chiming in and I must confess I don't have as much experience 
with crypto on z/VSE.  z/VSE may have changed, but in the past it has not 
provided a facility like ICSF which provides the interface to the CEX cards.

Going back to the original post, I suspect that the customer is using locally 
written assembler code to invoke the crypto instructions on the CPACF to 
encrypt the data before writing it to disk.  

How does the customer expect to drive work to the CEX card?  Is there a product 
that they plan on using?

z/VSE can use Total Storage devices which can provide encryption, but the 
encryption is done on the device, not on the CPACF hardware.  In this case, the 
Crypto Express card can be used to protect (encrypt) the symmetric key, using 
public key APIs,  and then that symmetric key is used in the device to encrypt 
or decrypt the data depending on whether it's a write or read operation.

In addition, z/VSE supports the Encryption Facility for z/VSE (a z/VSE 
implementation of the Encryption Facility for z/OS).  It can also provide 
similar support, using a public key to wrap the symmetric key that is then used 
to protect the data within the file.  As with the TotalStorage hardware, the 
CEX can 
perform these public key operations, but the encryption of the data is done 
elsewhere (not on the card).

But to use the CEX card to actually encrypt/decrypt the data a rest, would a) 
probably not provide acceptable performance and b) require another product to 
invoke the APIs that would be executed on the cards.

So, why is the customer considering installing the CEX card?  Is it to provide 
more security for their data at rest?  If so, what product do they expect to 
use to perform the encryption.  Bottom line, the CPACF and CEX are compatible, 
and in fact you must have the CPACF enabled to use the CEX cards, but using
the cards requires software that will leverage the cards.

Or is it for SSL operations?  The card can provide a significant performance 
boost for SSL operations and the real benefit is for authenticating the network 
communication sessions.  In this case, these public key operations are done on 
the CEX card instead of using software routines (MVC, SLL, Multiple 
instructions, etc.).

Along those lines, I want to clarify Todd Arnold's comments:
"If you use ICSF as the interface, it automatically selects the most 
appropriate crypto to use - for example, if you are doing clear-key encryption, 
it will automatically use CPACF because it knows that will be faster than the 
CEX ..."

Actually, the specific API that you implement in your code, not ICSF, 
determines which device will perform the work.  For example, CSNBSAE is the 
Symmetric Algorithm Encipher API and is a secure key API.  When you invoke that 
API, ICSF will always route the work to a CEX card (and there better be a 
card available to service that request or the API will fail).  On the other 
hand, if you invoke CSNBSYE, the Symmetric Key Encipher API, then ICSF will use 
the assembler instructions on the CPACF to perform that operation.  So ICSF is 
not deciding where the operation is performed, your choice of APIs is.

I hope that helps.
Greg Boyd
Mainframe Crypto
www.mainframecrypto.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Kirk Wolf]

"SSL" (or TLS) is a client-server secure connection protocol, not a
file/disk encryption protocol.

It involves both:
a) key exchange (handshake) which uses asymmetric key operations
 (handshake happens once or periodically for long sessions)

b) symmetric ciphers using a shared session key negotiated by (a)
 (ciphers are used for encrypting each block of data)

Crypto Express is the best for (a), but not for (b).
CPACF is best for (b), but doesn't do (a).

CPACF does either clear-key or wrapped-key symmetric ciphers.

S/MIME, which is similar to SSL would be commonly used for file encryption,
as would CMS or PGP.
For any of these, the actual cipher (AES) would be best done with CPACF on
z.

FWIW, you can use CPACF Ciphers via ICSF calls or direct use of  the CPACF
instructions.



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, Jun 15, 2017 at 1:14 AM, Arye Shemer  wrote:

> Hello Todd,
> I'll try answer your questions as best I can.
> 1. I am talking about  z/VM z/VSE customer who is using currently CPACF to
> encrypt data going to the disk and (I am not sure)
> some software using CPACF for SSL.
> 2. Customer predict workload increase and expect to get more performance
> using the Crypto Express especially in the growing SSL
> demand
> 3. Customer is currently using CPACF with key length of 128  bits for clear
> key encryption and (by internal demand) expect to move to 256 bits with the
> Crypto Express
> 4. As far as I know there are no immediate requirements for high secured
>  key protection (which provided of course
> by the Crypto Express)
> 5. The Crypto Express is offered to the customer for marketing reasons (Can
> not  elaborate and have to leave it vague)
>
> Thanks for your interests and suggestions,
>
> Arye.
>
> On Wed, Jun 14, 2017 at 3:46 PM, Todd Arnold  wrote:
>
> > As Phil said:
> > > (arguably the firmware is slightly less secure than the
> tamper-resistant
> > HSM, but the memory
> > > used in the firmware to hold that key is protected-it's apparently not
> > even visible in HMC dumps)
> >
> > That is correct.  The memory where the key is held is associated with the
> > CPACF hardware and its operation.  That memory is part of the internal z
> > hardware and is completely separate from any memory that the applications
> > or operating system can see or use.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Phil Smith]

Arye Shemer wrote:
>I'll try answer your questions as best I can.
>1. I am talking about  z/VM z/VSE customer who is using currently CPACF to
>encrypt data going to the disk and (I am not sure)
>some software using CPACF for SSL.

>2. Customer predict workload increase and expect to get more performance
>using the Crypto Express especially in the growing SSL
>demand

For SSL, yes; for basic encryption, no. It will almost certainly be slower. If 
the blocks are big enough it's possible it might be faster, but I wouldn't bet 
on it (well, I guess it depends how bad their software encryption 
implementation is).

>3. Customer is currently using CPACF with key length of 128  bits for clear
>key encryption and (by internal demand) expect to move to 256 bits with the
>Crypto Express

Again, if this is for basic AES/DES and the existing implementation isn't too 
horrible, don't bet on better performance.

>4. As far as I know there are no immediate requirements for high secured
> key protection (which provided of course
>by the Crypto Express)

>5. The Crypto Express is offered to the customer for marketing reasons (Can
>not  elaborate and have to leave it vague)

Um. OK. Not sure what that means, but I guess that's the point!
--

...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
HPE Data Security

phs...@hpe.com
T 703-476-4511
M 703-568-6662
Hewlett Packard Enterprise
Herndon, VA


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Arye Shemer]

Hello Todd,
I'll try answer your questions as best I can.
1. I am talking about  z/VM z/VSE customer who is using currently CPACF to
encrypt data going to the disk and (I am not sure)
some software using CPACF for SSL.
2. Customer predict workload increase and expect to get more performance
using the Crypto Express especially in the growing SSL
demand
3. Customer is currently using CPACF with key length of 128  bits for clear
key encryption and (by internal demand) expect to move to 256 bits with the
Crypto Express
4. As far as I know there are no immediate requirements for high secured
 key protection (which provided of course
by the Crypto Express)
5. The Crypto Express is offered to the customer for marketing reasons (Can
not  elaborate and have to leave it vague)

Thanks for your interests and suggestions,

Arye.

On Wed, Jun 14, 2017 at 3:46 PM, Todd Arnold  wrote:

> As Phil said:
> > (arguably the firmware is slightly less secure than the tamper-resistant
> HSM, but the memory
> > used in the firmware to hold that key is protected-it's apparently not
> even visible in HMC dumps)
>
> That is correct.  The memory where the key is held is associated with the
> CPACF hardware and its operation.  That memory is part of the internal z
> hardware and is completely separate from any memory that the applications
> or operating system can see or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Todd Arnold]

As Phil said:
> (arguably the firmware is slightly less secure than the tamper-resistant HSM, 
> but the memory 
> used in the firmware to hold that key is protected-it's apparently not even 
> visible in HMC dumps)

That is correct.  The memory where the key is held is associated with the CPACF 
hardware and its operation.  That memory is part of the internal z hardware and 
is completely separate from any memory that the applications or operating 
system can see or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Todd Arnold]

Since I design some of this stuff, I can help clarify - but others have already 
done a pretty good job of explaining the various alternatives.

What I'd like to ask is what you are actually trying to do?  What is the reason 
for installing the Crypto Express and trying to use it instead of or in 
addition to the CPACF?  The reason I'd expect is that you want additional 
security for your keys, but I don't think you've confirmed that.

If you use ICSF as the interface, it automatically selects the most appropriate 
crypto to use - for example, if you are doing clear-key encryption, it will 
automatically use CPACF because it knows that will be faster than the CEX, but 
if you want to do PIN block translation it knows it has to use the CEX because 
the relevant standards mandate that keys can't be in the clear and that the 
entire translation operation has to be done atomically.

Most people find that CEX performance is not good enough for disk encryption 
applications, so they either use clear-key CPACF or protected-key CPACF, 
depending on their security requirements on the keys.  Performance for 
protected-key operations is only slightly less than for clear-key ones with 
CPACF - you can see some performance information in this paper:  
https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw03283usen/ZSW03283USEN.PDF

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Arye Shemer]

Thank you all for your contribution and time.
It sure gave me a lot to think of.

thanks,

Arye.

On Mon, Jun 12, 2017 at 6:44 PM, Phil Smith  wrote:

> There are several things intertwined here.
>
>
> *   CPACF is the "crypto on the chip" - z Systems instructions that do
> AES et al.
>
> *   CEX is the z HSM.
>
> *   ICSF is, of course, the z/OS service that talks to both (though
> you can do CPACF operations directly as well).
>
> With just CPACF, you're forced to use what's called Clear Key operation:
> keys are stored (somewhere, somehow-perhaps in CKDS), are fetched, and are
> passed to CPACF to do operations.
>
> With CEX in the mix, you add two more options: Secure Key and Protected
> Key.
>
> Secure Key means that keys are generated by the CEX, wrapped (encrypted)
> using keys known only to the CEX, and then passed to z/OS, which stores
> them (usually in CKDS). When an operation is performed, that wrapped key
> and the data are passed to the CEX, which unwraps the key, does the
> operation, and returns the result. Very secure, if relatively slow.
>
> Protected Key means that keys are generated by the CEX, wrapped, and
> stored in CKDS, like Secure Key. BUT when an operation is needed, an ICSF
> call takes that wrapped key and passes it to the CEX, where it is
> unwrapped, rewrapped using an ephemeral key generated just for the current
> IPL, and that key is returned. That ephemeral key is also passed to the
> firmware, so it's available to CPACF. Then the actual operation is
> performed by passing the rewrapped key: CPACF unwraps it using that
> ephemeral key, does the operation, returns the result. And ICSF remembers
> that it's done this, so the next operation using that key doesn't talk to
> the HSM at all. This gets you almost all of the performance and pretty well
> all of the security of Secure Key (arguably the firmware is slightly less
> secure than the tamper-resistant HSM, but the memory used in the firmware
> to hold that key is protected-it's apparently not even visible in HMC
> dumps).
>
> So your customer can switch to using Protected Key, at least in theory.
> How hard this is will depend on how keys are generated and managed now, as
> well as whether they're using ICSF or 'raw' CPACF now, as well as whether
> they're up for reprotecting all of their existing data with the new key.
>
> Does this help?
> --
> ...phsiii
>
> Phil Smith III
> Senior Architect & Product Manager, Mainframe & Enterprise
> Distinguished Technologist
> HPE Data Security
>
> phs...@hpe.com
> T 703-476-4511
> M 703-568-6662
> Hewlett Packard Enterprise
> Herndon, VA
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Phil Smith]

There are several things intertwined here.


*   CPACF is the "crypto on the chip" - z Systems instructions that do AES 
et al.

*   CEX is the z HSM.

*   ICSF is, of course, the z/OS service that talks to both (though you can 
do CPACF operations directly as well).

With just CPACF, you're forced to use what's called Clear Key operation: keys 
are stored (somewhere, somehow-perhaps in CKDS), are fetched, and are passed to 
CPACF to do operations.

With CEX in the mix, you add two more options: Secure Key and Protected Key.

Secure Key means that keys are generated by the CEX, wrapped (encrypted) using 
keys known only to the CEX, and then passed to z/OS, which stores them (usually 
in CKDS). When an operation is performed, that wrapped key and the data are 
passed to the CEX, which unwraps the key, does the operation, and returns the 
result. Very secure, if relatively slow.

Protected Key means that keys are generated by the CEX, wrapped, and stored in 
CKDS, like Secure Key. BUT when an operation is needed, an ICSF call takes that 
wrapped key and passes it to the CEX, where it is unwrapped, rewrapped using an 
ephemeral key generated just for the current IPL, and that key is returned. 
That ephemeral key is also passed to the firmware, so it's available to CPACF. 
Then the actual operation is performed by passing the rewrapped key: CPACF 
unwraps it using that ephemeral key, does the operation, returns the result. 
And ICSF remembers that it's done this, so the next operation using that key 
doesn't talk to the HSM at all. This gets you almost all of the performance and 
pretty well all of the security of Secure Key (arguably the firmware is 
slightly less secure than the tamper-resistant HSM, but the memory used in the 
firmware to hold that key is protected-it's apparently not even visible in HMC 
dumps).

So your customer can switch to using Protected Key, at least in theory. How 
hard this is will depend on how keys are generated and managed now, as well as 
whether they're using ICSF or 'raw' CPACF now, as well as whether they're up 
for reprotecting all of their existing data with the new key.

Does this help?
--
...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
HPE Data Security

phs...@hpe.com
T 703-476-4511
M 703-568-6662
Hewlett Packard Enterprise
Herndon, VA


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[R.S.]

W dniu 2017-06-12 o 14:12, Tony Thigpen pisze:
We are talking about encrypting "Data at Rest". There is *no* key 
exchange involved. The only purpose for encrypting keys is so you can 
send them to someone else.


No. The purpose of encrypting keys is something called "secure key 
cryptography", as opposed to "clear key cryptography" and it is NOT 
related to kye exchange.

In short words:
Secure key cryptography (SKC) means the key is not available even for 
people with administration authorities, cannot be dumped with memory, 
etc. The key resides in clear form only inside secure (tamper-proof) 
crypto device.
Clear key cryptography (CKC) means a person with authorities and 
knowledge can obtain the key value.


Crypto cards are required for SKC, but it is slower than CPACF.
CPACF support CKC and something called "Protected Key Cryptography" - in 
such mode the key is masked, so even authorized insider is not able to 
obtain the key value, but it is not certified as SKC (but runs at the 
speed of CPACF).



Now key echange. In any mode it is possible to exchange keys securely or 
not securely.



--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Mark Jacobs - Listserv]

Has nothing to do with key exchange. The DEK used to encrypt the data 
will be in clear text rather than the DEK being encrypted by the KEK. ( 
ICSF Master Key ).


Mark Jacobs


Tony Thigpen 
June 12, 2017 at 8:12 AM
We are talking about encrypting "Data at Rest". There is *no* key 
exchange involved. The only purpose for encrypting keys is so you can 
send them to someone else.


Tony Thigpen



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mark Jacobs - Listserv 
June 12, 2017 at 8:01 AM
Encryption/decryption without a CryptoExpress only supports clear 
keys, not protected or secured encryption keys. Might be enough for 
the OP, but wouldn't fly in my environment.




Tony Thigpen 
June 12, 2017 at 7:22 AM
For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.

Tony Thigpen



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Tony Thigpen]

We are talking about encrypting "Data at Rest". There is *no* key 
exchange involved. The only purpose for encrypting keys is so you can 
send them to someone else.


Tony Thigpen

Mark Jacobs - Listserv wrote on 06/12/2017 08:01 AM:

Encryption/decryption without a CryptoExpress only supports clear keys,
not protected or secured encryption keys. Might be enough for the OP,
but wouldn't fly in my environment.



Tony Thigpen 
June 12, 2017 at 7:22 AM
For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.

Tony Thigpen



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Please be alert for any emails that may ask you for login information
or directs you to login via a link. If you believe this message is a
phish or aren't sure whether this message is trustworthy, please send
the original message as an attachment to 'phish...@timeinc.com'.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Mark Jacobs - Listserv]

Encryption/decryption without a CryptoExpress only supports clear keys, 
not protected or secured encryption keys. Might be enough for the OP, 
but wouldn't fly in my environment.




Tony Thigpen 
June 12, 2017 at 7:22 AM
For encrypting "data at rest", the CPACF is really all he needs. The
Crypto Express is intended to speed up key negotiations between sites,
something not needed for his intended plans.

Tony Thigpen



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Tony Thigpen]

For encrypting "data at rest", the CPACF is really all he needs. The 
Crypto Express is intended to speed up key negotiations between sites, 
something not needed for his intended plans.


Tony Thigpen

Arye Shemer wrote on 06/12/2017 02:00 AM:

Hello,

Customer is currently using CPACF to encrypt his data before writing to
disks.

Customer intent to purchased Crypto Express and want to use it to continue
to encrypt the data before writing  to the disks,

Are there any compatibility issues ?

Are there any know documents which deals/explain with  issues involved ?

Thanks,

Arye Shemer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Customer is Using CPACF (Crypto) purchased Crypto Express

[Arye Shemer]

Hello,

Customer is currently using CPACF to encrypt his data before writing to
disks.

Customer intent to purchased Crypto Express and want to use it to continue
to encrypt the data before writing  to the disks,

Are there any compatibility issues ?

Are there any know documents which deals/explain with  issues involved ?

Thanks,

Arye Shemer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN