USEC Encrypt/Decrypt Question

"William B. Norton" <wbn@umich.edu> Tue, 07 May 1996 19:44 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25353; 7 May 96 15:44 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25348; 7 May 96 15:44 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa14521; 7 May 96 15:44 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa06978; 7 May 96 14:55 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa06962; 7 May 96 14:45 EDT
Received: by relay.tis.com; id OAA15055; Tue, 7 May 1996 14:46:36 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma015049; Tue, 7 May 96 14:46:11 -0400
Received: from relay.tis.com by tis.com (4.1/SUN-5.64) id AA11305; Tue, 7 May 96 14:46:27 EDT
Received: by relay.tis.com; id OAA15045; Tue, 7 May 1996 14:46:06 -0400
Received: from rodan.rs.itd.umich.edu(141.211.83.21) by relay.tis.com via smap (V3.1) id xma015043; Tue, 7 May 96 14:45:51 -0400
Received: from wander.merit.edu by rodan.rs.itd.umich.edu (8.7.5/2) id OAA23037; Tue, 7 May 1996 14:48:32 -0400 (EDT)
Message-Id: <199605071848.OAA23037@rodan.rs.itd.umich.edu>
Date: Tue, 07 May 1996 14:48:32 -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: snmpv2@tis.com
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "William B. Norton" <wbn@umich.edu>
Subject: USEC Encrypt/Decrypt Question
X-Orig-Sender: snmpv2-approval@neptune.tis.com
Precedence: bulk

The USEC spec says (bottom of page 9 rfc1910):

   The length of an octet sequence to be encrypted by the DES must be an
   integral multiple of 8.  When encrypting, the data is padded at the
   end as necessary; the actual pad value is irrelevant.

   If the length of the octet sequence to be decrypted is not an
   integral multiple of 8 octets, the processing of the octet sequence
   is halted and an appropriate exception noted.  When decrypting, the
   padding is ignored.

It sounds like we are sending the padding across the net.  Which sequence
lengths get updated?  Is the padding considered part of the PDU?  Part of
the message?

It seems we are adding complexity by sending the padding over the wire. The
agent has to do the decrypt and then figure out which bytes are exptraneous.
Wouldn't it be cleaner to do have encryptor/decryptor routines pad, crypt,
and toss the padding?  That way the PDU processing is totally uneffected by
the optional cryptography.

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