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
- USEC Encrypt/Decrypt Question William B. Norton
- Re: USEC Encrypt/Decrypt Question Uri Blumenthal