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
- USEC DES privKey William B. Norton
- Re: USEC DES privKey D.Scott.Thomas
- Re: USEC DES privKey Uri Blumenthal
- Re: USEC DES privKey William B. Norton
- Re: USEC DES privKey Uri Blumenthal