Re: USEC DES privKey

"William B. Norton" <wbn@umich.edu> Wed, 01 May 1996 22:06 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04214; 1 May 96 18:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04208; 1 May 96 18:06 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa16192; 1 May 96 18:06 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa23030; 1 May 96 17:21 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa22978; 1 May 96 17:13 EDT
Received: by relay.tis.com; id RAA27536; Wed, 1 May 1996 17:14:50 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma027507; Wed, 1 May 96 17:14:22 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA20212; Wed, 1 May 96 17:14:42 EDT
Received: by relay.tis.com; id RAA27498; Wed, 1 May 1996 17:14:20 -0400
Received: from rodan.rs.itd.umich.edu(141.211.83.21) by relay.tis.com via smap (V3.1) id xma027492; Wed, 1 May 96 17:14:13 -0400
Received: from wander.merit.edu by rodan.rs.itd.umich.edu (8.7.5/2) id RAA25615; Wed, 1 May 1996 17:16:07 -0400 (EDT)
Message-Id: <199605012116.RAA25615@rodan.rs.itd.umich.edu>
Date: Wed, 01 May 1996 17:16:07 -0400
X-Sender: wbn@w.imap.itd.umich.edu
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: uri@watson.ibm.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "William B. Norton" <wbn@umich.edu>
Subject: Re: USEC DES privKey
Cc: snmpv2@tis.com
X-Orig-Sender: snmpv2-approval@neptune.tis.com
Precedence: bulk

Uri - will you send me your phone # so we can try an interoperability test soon?

Thanks.  Responses to your questions follow....

>Is it DES by Stig Ostholm from Chalmers Univ. of Technology?
>I tried to get to "ftp.std.com" but the access is flakey...

The DES code I retrieved according to the COPYRIGHT is by Anitti Louko
(alo@kampi.hut.fi)

>> a) Should the initialization vector be initialized to all zeros as the
>> sample des code does?
>
>No. Just give it a *copy* of the second 64-bit word you got from
>password-to-key. In case you don't process the whole data that
>needs to be encrypted/decrypted - pass that ptr to that copy
>along with the new data to process.

I don't understand.  I understand that I get the first 8 bytes from
string_to_key(passwd,&privKey).  I don't get a "second 64-bit word" back 
from string_to_key(), just a single 8 byte key.

>> b) Should the initialization vector get updated with the "final" vector?
>> ( I suspect not, since an updated vector and a lost packet would break
>> communication.)  Generally, does the initialization vector remain constant
>> (perhaps zeros) forever?
>
>Well, the IV that subroutine deals with - you can treat as a
>"current state indicator" or a "stage preserver". Certainly 
>it will change as bore and more bytes of data are piped
>through the encryption engine.
>
>Now, since you do need the original IV, you can/should preserve
>it in a separate buffer [and give a *copy* of it to the 
>cbc_encrypt() routine].
>
>Note that our protocol contains a minor weakness - namely that IV
>doesn't change from packet to packet. This sort of defeats the
>purpose of IV which is to make two encrypted texts that begin
>with the same plaintext, have different ciphertext beginnings.

Again, I am having trouble understanding your message. 

First you say that the initialization vector (IV) changes as more data is
processed.  If truem then I think we have a problem.  ( Since packets get
lost, and the IV can change, how do we keep agent/NMS synchronized? )

Then it seems that you are saying yes, the initialization vector will never
change.

For USEC SNMPv2, which statement is right?  And where how do I get the IV?

Bill
----------------------------------------------------------------------------
-----
William Norton			<wbn@merit.edu>			(313) 936-2656