ADSM-L

Re: Encryption

1994-11-07 14:31:54
Subject: Re: Encryption
From: Nick Laflamme <NLAFLAMM AT VMA.CC.ND DOT EDU>
Date: Mon, 7 Nov 1994 14:31:54 EST
On Mon, 7 Nov 1994 10:05:38 PST "Paul L. Bradshaw" said:
>We are looking at encryption, but one of the key stumbling blocks is in the
>area of key management.
>
>Questions:
>
>1.  Should ADSM allow for keys to be changed on a time basis?

I would think so!

>2.  Should ADSM administrators set the keys and provide to end users, end
>    users only set the keys, a combination of above under admin control, etc?

You're going to need cooperation from both the users and the administrators
unless you're storing the data in encrypted format (see below).  I would
see a system where the user sets the key on the client and the
administrator sets the key on the host.  I'm not current enough on public
key encryption to guess if methods like that can be used to send keys in
the clear over the network.  My gut reaction is not, but that probably
reflects my ignorance.  :-)

>3.  If keys are allowed to be changed, then is the user/site willing to
>    sign up for prompting the end user to enter key-1, key-2, ... key-n
>    for all files to be restored?

I would guess not.  I have enough trouble remembering past logon passwords!

>4.  Is encryption just needed for transmission and not storage?  ie:
>    encrypt the data over the wire with the session key, but decrypt it before
>    it is stored since the physical media is protected?  Are sites willing
>    to take the performance penalty for the dual encryption?

I would vote for tranmission only myself.  If some other client is
authorized to get files from my backups, I shouldn't have to give him or
her my keys, right?

What do you mean by "dual encryption?" Storing in the clear and encrypting
for transmission in both directions?  I think we'd accept that.

>There are a lot of questions, and depending on what type of industry your
>company is in will dictate your requirements.  Please let us know what you
>would like in a priority order.  Thanks,

I think my users who are worried about such issues would accept independent
input of keys by administrators with encryption for transmission only.

Administrative transactions should be encrypted if any data is.  That would
let me enter a key for a client over the network because the key itself
would be encrypted in my administrative session.  (At some point I need to
log on a secure terminal to enter the first key.  C'est la vie.)

We're a university with all of our users geographically close to us.
Encryption would calm some fears, and we'll accept CPU cycle losses at both
ends to support this, but I don't want to store encrypted data (unless the
user encrypts the data before ADSM sees it).

Thanks for asking,
Nick

* Intelligence demands reasons, not rules.
<Prev in Thread] Current Thread [Next in Thread>