On: Thu, May 04, 2006 at 09:47:10AM -0500,Mike Walter Wrote:
} Ferdinand,
}
} I do admit to being suspicious that some recent posts have not made it
} through our spam filters, but for this topic I even logged onto the IBMVM
} listserv and cannot find the topic in May or even April, 2006.
Mike, jou didn't go back far enough.
> search "encryption" in IBMVM since 06/1/1
-> 17 matches.
Item # Date Time Recs Subject
------ ---- ---- ---- -------
060746 06/02/07 21:57 45 Re: print files from z/VM (rscs) to linux cups
printer
061314 06/03/08 15:17 43 Re: Requirements for encrypting tape drives for
z/VM
061315 06/03/08 16:40 29 Re: Requirements for encrypting tape drives for
z/VM
061320 06/03/08 17:11 32 Re: Requirements for encrypting tape drives for
z/VM
061325 06/03/08 23:06 59 Re: Requirements for encrypting tape drives for
z/VM
061332 06/03/09 10:38 55 Re: Requirements for encrypting tape drives for
z/VM
061348 06/03/09 17:49 53 Re: Requirements for encrypting tape drives for
z/VM
061350 06/03/10 00:06 93 Re: Requirements for encrypting tape drives for
z/VM
061354 06/03/10 10:18 36 Re: Requirements for encrypting tape drives for
z/VM
061355 06/03/10 09:30 50 Re: Requirements for encrypting tape drives for
z/VM
061356 06/03/10 10:36 68 Re: Requirements for encrypting tape drives for
z/VM
061357 06/03/10 09:47 47 Re: Requirements for encrypting tape drives for
z/VM
061360 06/03/10 11:55 34 Re: Requirements for encrypting tape drives for
z/VM
061363 06/03/10 22:45 69 Re: Requirements for encrypting tape drives for
z/VM
061366 06/03/13 09:35 102 Re: Requirements for encrypting tape drives for
z/VM
061751 06/03/29 22:15 207 Re: Draft requirements for 2006 WAVV up for
comments
061759 06/03/30 09:01 91 Re: Draft requirements for 2006 WAVV up for
comments
To order a copy of these postings, send the following command:
GETPOST IBMVM 60746 61314-61315 61320 61325 61332 61348 61350 61354-61357
61360 61363 61366 61751 61759
>>> Item #60746 (7 Feb 2006 21:57) - Re: print files from z/VM (rscs) to linux
>>> cups printer
keys, and ensure that your cupsd is built with SSL support. You can
then supply any supported OpenSSL authentication/encryption method, and
^^^^^^^^^^
it "just works". The SuSE one probably is (it's got every other option
>>> Item #61314 (8 Mar 2006 15:17) - Re: Requirements for encrypting tape
>>> drives for z/VM
backups. With only S/W products and the crypto engines currently
available, it looks like encryption in the hardware will be our only
^^^^^^^^^^
viable option. So...we don't require it now but will in the not so
>>> Item #61315 (8 Mar 2006 16:40) - Re: Requirements for encrypting tape
>>> drives for z/VM
Emulated 3490 to inline SCSI encryption device to SCSI 3490-F01 on the
^^^^^^^^^^
MP3K, emulated 3490 to inline SCSI encryption device to DLT on Flex
^^^^^^^^^^
boxen.=20
>>> Item #61320 (8 Mar 2006 17:11) - Re: Requirements for encrypting tape
>>> drives for z/VM
>
In that case, tape encryption is becoming a requirement where I work, but it
^^^^^^^^^^
will probably be done on the host until we find out it's gonna chew up too many
>>> Item #61325 (8 Mar 2006 23:06) - Re: Requirements for encrypting tape
>>> drives for z/VM
tape drives for DR backups, so it's not affected by this requirement.
We briefly used the encryption feature in VM:Backup for DR backups of a
^^^^^^^^^^
smaller system, but VM:Backup uses the DES algorithm, which isn't on our
approved list. We had to continue hand-carrying the tapes, so we turned
off the encryption. AES is our preferred encryption algorithm, but
^^^^^^^^^^
Triple DES and a couple of others are also acceptable.
>>> Item #61332 (9 Mar 2006 10:38) - Re: Requirements for encrypting tape
>>> drives for z/VM
include=20
encryption on all critical data that leaves the data centers.
^^^^^^^^^^
>>> Item #61348 (9 Mar 2006 17:49) - Re: Requirements for encrypting tape
>>> drives for z/VM
encryption support in the emulated tape control units in the next FLEX-ES=
^^^^^^^^^^
V7
***************
n
disk only and not SCSI tapes. As mentioned, a hardware encryption device=
^^^^^^^^^^
***************
>
>Emulated 3490 to inline SCSI encryption device to SCSI 3490-F01 on the
^^^^^^^^^^
>MP3K, emulated 3490 to inline SCSI encryption device to DLT on Flex
^^^^^^^^^^
>boxen.=20
>>> Item #61350 (10 Mar 2006 00:06) - Re: Requirements for encrypting tape
>>> drives for z/VM
support industrial-
strength encryption. Phoo!
^^^^^^^^^^
If there is an encryption solution, it should either use the hardware enc=
^^^^^^^^^^
ryption facilities of the z9=20
hardware, or offboard encryption hardware.
^^^^^^^^^^
***************
data -- compression must come first. Tape-drive compression is worthless =
if the encryption is on=20
^^^^^^^^^^
the mainframe.
***************
>tape drives for DR backups, so it's not affected by this requirement.
>We briefly used the encryption feature in VM:Backup for DR backups of a
^^^^^^^^^^
>smaller system, but VM:Backup uses the DES algorithm, which isn't on our=
***************
>off the encryption. AES is our preferred encryption algorithm, but
^^^^^^^^^^
>Triple DES and a couple of others are also acceptable.
>>> Item #61354 (10 Mar 2006 10:18) - Re: Requirements for encrypting tape
>>> drives for z/VM
>> If there is an encryption solution, it should either use the hardware
^^^^^^^^^^
>> encryption facilities of the z9
^^^^^^^^^^
>> hardware, or offboard encryption hardware.
^^^^^^^^^^
>>=20
***************
worthless
>> if the encryption is on
^^^^^^^^^^
>> the mainframe.
>>> Item #61355 (10 Mar 2006 09:30) - Re: Requirements for encrypting tape
>>> drives for z/VM
>
>>> If there is an encryption solution, it should either use the
^^^^^^^^^^
>>> hardware
>>> encryption facilities of the z9
^^^^^^^^^^
>>> hardware, or offboard encryption hardware.
^^^^^^^^^^
>>>
***************
> worthless
>>> if the encryption is on
^^^^^^^^^^
>>> the mainframe.
***************
Would be lousy: in fact, it should be impossible to compress an
encrypted stream. Specifically, encryption makes your data stream
^^^^^^^^^^
look like random bits, and random bits don't compress at all. If
***************
Well, sure, but that's the case with any encryption and compression
^^^^^^^^^^
scheme: encrypting a compressed stream will yield a different answer
>>> Item #61356 (10 Mar 2006 10:36) - Re: Requirements for encrypting tape
>>> drives for z/VM
>> >
>> >>> If there is an encryption solution, it should either use the
^^^^^^^^^^
>> >>> hardware
>> >>> encryption facilities of the z9
^^^^^^^^^^
>> >>> hardware, or offboard encryption hardware.
^^^^^^^^^^
>> >>>
***************
>> > worthless
>> >>> if the encryption is on
^^^^^^^^^^
>> >>> the mainframe.
***************
>> Would be lousy: in fact, it should be impossible to compress an
>> encrypted stream. Specifically, encryption makes your data stream
^^^^^^^^^^
>> look like random bits, and random bits don't compress at all. If
***************
>>=20
>> Well, sure, but that's the case with any encryption and compression
^^^^^^^^^^
>> scheme: encrypting a compressed stream will yield a different answer
>>> Item #61357 (10 Mar 2006 09:47) - Re: Requirements for encrypting tape
>>> drives for z/VM
>>
>>>> If there is an encryption solution, it should either use the
^^^^^^^^^^
>>>> hardware
>>>> encryption facilities of the z9
^^^^^^^^^^
>>>> hardware, or offboard encryption hardware.
^^^^^^^^^^
>>>>
***************
>> worthless
>>>> if the encryption is on
^^^^^^^^^^
>>>> the mainframe.
***************
>Would be lousy: in fact, it should be impossible to compress an
>encrypted stream. Specifically, encryption makes your data stream
^^^^^^^^^^
>look like random bits, and random bits don't compress at all.
>>> Item #61360 (10 Mar 2006 11:55) - Re: Requirements for encrypting tape
>>> drives for z/VM
I've been interested in this topic, but I wonder about the usefulness
of an encryption mechanism in a tape drive, if you have to go to a DR
^^^^^^^^^^
site without the decryption hardware.
***************
software, and fed into the drive at the point where the encrypted portion
of the tape starts. Then, if the hardware encryption was NOT available, a
^^^^^^^^^^
compatible backup or restore could be done by having the backup software use
software encryption/decryption instead.
^^^^^^^^^^
>>> Item #61363 (10 Mar 2006 22:45) - Re: Requirements for encrypting tape
>>> drives for z/VM
Any good encryption algorithm will produce text that is 100% "random". If=
^^^^^^^^^^
it isn't, that would give=20
someone a hook to decrypt it. Put it another way, let's say you use a 256=
bit encryption key, and=20
^^^^^^^^^^
then after encryption you compress the the resulting text to 75%, then in=
^^^^^^^^^^
effect you only got 75%=20
of 256 bits =3D 192 bits worth of encryption. In fact, as others pointed =
^^^^^^^^^^
out, most compression=20
***************
So plain text -> compression -> encryption -> media will be smaller than =
^^^^^^^^^^
the original plain text,=20
but plain text -> encryption -> compression -> media will be the same siz=
^^^^^^^^^^
e (or larger) than the=20
***************
This phenomenon bit my boss -- when the Bank introduced VPN encryption as=
^^^^^^^^^^
a requirement to=20
***************
>
>>> If there is an encryption solution, it should either use the hardware=
^^^^^^^^^^
>>> encryption facilities of the z9
^^^^^^^^^^
>>> hardware, or offboard encryption hardware.
^^^^^^^^^^
>>>=20
***************
>worthless
>>> if the encryption is on
^^^^^^^^^^
>>> the mainframe.
>>> Item #61366 (13 Mar 2006 09:35) - Re: Requirements for encrypting tape
>>> drives for z/VM
about=20
encryption and compression. I am starting to review and understand
^^^^^^^^^^
encryption. I need to understand the pro/cons/etc..
^^^^^^^^^^
***************
>>=20
>> Any good encryption algorithm will produce text that is 100%
^^^^^^^^^^
"random". If
***************
256
>> bit encryption key, and
^^^^^^^^^^
>> then after encryption you compress the the resulting text to 75%,
^^^^^^^^^^
then in
>> effect you only got 75%
>> of 256 bits =3D 192 bits worth of encryption. In fact, as others
^^^^^^^^^^
pointed
***************
>>=20
>> So plain text -> compression -> encryption -> media will be smaller
^^^^^^^^^^
than
>> the original plain text,
>> but plain text -> encryption -> compression -> media will be the same
^^^^^^^^^^
>> size (or larger) than the
***************
>> This phenomenon bit my boss -- when the Bank introduced VPN
encryption as
^^^^^^^^^^
>> a requirement to
***************
>> >
>> >>> If there is an encryption solution, it should either use the
^^^^^^^^^^
hardware
>> >>> encryption facilities of the z9
^^^^^^^^^^
>> >>> hardware, or offboard encryption hardware.
^^^^^^^^^^
>> >>>
***************
>> >worthless
>> >>> if the encryption is on
^^^^^^^^^^
>> >>> the mainframe.
>>> Item #61751 (29 Mar 2006 22:15) - Re: Draft requirements for 2006 WAVV up
>>> for comments
you mention breaks two of the fundamental pieces of IPv6 (in IPv6, TLS =
encryption and endpoint authentication support are required features), =
^^^^^^^^^^
so you really can't rely on it being acceptable long-term. If we =
***************
lot of other stuff going on in IPv6 that is impossible to adduce from =
just the IPv4 stream (cf encryption and endpoint auth support discussed =
^^^^^^^^^^
above, among other goodies). Most IPv6-aware routers are operating two =
***************
mention breaks two of the fundamental pieces of IPv6 (in IPv6, TLS =
encryption =0A=
^^^^^^^^^^
and endpoint authentication support are required features), so you =
***************
IPv4 =0A=
stream (cf encryption and endpoint auth support discussed above, among =
^^^^^^^^^^
other =0A=
>>> Item #61759 (30 Mar 2006 09:01) - Re: Draft requirements for 2006 WAVV up
>>> for comments
> you mention breaks two of the fundamental pieces of IPv6 (in IPv6, TLS
> encryption and endpoint authentication support are required features),
^^^^^^^^^^
> so you really can't rely on it being acceptable long-term. If we
***************
> lot of other stuff going on in IPv6 that is impossible to adduce from
> just the IPv4 stream (cf encryption and endpoint auth support discussed
^^^^^^^^^^
> above, among other goodies). Most IPv6-aware routers are operating two
--
Rich Greenberg N6LRT Marietta, GA, USA richgr atsign panix.com + 1 770 321 6507
Eastern time zone. I speak for myself & my dogs only. VM'er since CP-67
Canines:Val, Red & Shasta (RIP),Red, husky Owner:Chinook-L
Atlanta Siberian Husky Rescue. www.panix.com/~richgr/ Asst Owner:Sibernet-L
