Perplexed by padding values (was "padding values")
Bob Monsour <rmonsour@hifn.com> Sat, 31 May 1997 13:16 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA25545 for ipsec-outgoing; Sat, 31 May 1997 09:16:44 -0400 (EDT)
Message-Id: <3.0.32.19970530171142.00b51320@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 30 May 1997 17:12:38 -0700
To: William Allen Simpson <wsimpson@greendragon.com>
From: Bob Monsour <rmonsour@hifn.com>
Subject: Perplexed by padding values (was "padding values")
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Bill, At 04:04 PM 5/24/97 GMT, William Allen Simpson wrote: >Remembering that you like to use the same technique in multiple venues, >I'll point out that these values are used in PPP DES encryption. In looking at RFC1969 (The PPP DES Encryption Protocol (DESE), 6/96), it refers to RFC1570 (PPP LCP Extension, 1/94) for the self-described padding option. Note that a more recent version, in draft-ietf-pppext-lcpext-ds-01.txt (11/96) provides a similar description of padding. In those specs, the padding values start at '1', not '0' as you proposed in your DES/3DES drafts. While there is no pad length field in those specs, am I missing something with respect to the reason that your recent DES/3DES drafts start the padding at zero rather than one? As an example, in DESE, 3 bytes of padding would be represented by padding values of 1, 2, 3. In your recent DES/3DES drafts, 3 bytes of padding would be represented by padding values of 0, 1, 2, followed by a pad length field of 3. Is it simply the relative elegance of a monotonically increasing values of padding leading up to the pad length byte? For those of us trying to implement somewhat flexible hardware to support a variety of security protocols, including padding options/modes, this kind of tweak matters. I propose that we do as DESE does and start with a value of '1' unless there is a compelling security argument to be made. Regards, -Bob At 04:04 PM 5/24/97 GMT, William Allen Simpson wrote: >On the differences in text on padding values: > >> From: Bob Monsour <rmonsour@earthlink.net> >> While I understand that you believe that it's important for the >> algorithm/transform documents to repeat certain field definitions from the >> base ESP document, in this case I find it couter-productive and prone to >> inducing errors. Let's take an example from from your DES draft >> (draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft >> and RFC1829. It states: >> >> Padding zero or more octets. >> >> Prior to encryption, this field is filled with a >> series of integer values (beginning with zero), to >> align the Pad Length and Payload Type fields at the >> end of an eight octet boundary (counted from the >> beginning of the Payload Data). >> >> After decryption, it is examined for a valid series >> of integer values. >> >> This field is opaque. That is, the value is set >> prior to encryption, and is examined only after >> decryption. >> >Please read this in the context of the whole paper. See also: > >2.2. Decryption >... > The Pad Length is removed and examined. If pad checking is config- > ured, and the padding octets are not the correct values for the Pad > Length, then the payload is discarded, and the "Decryption Failed" > error is indicated [RFC-xxxx]. >... > >Operational Considerations >... > Pad Check > Some earlier implementations used random pad values. > > Default: Off. >... > >The default is off because of interoperability concerns. > > >> In the "new" ESP draft (section 2.5) padding is defined as follows: >> >> The Padding bytes SHOULD be initialized with random data and they are >> transmitted. The transmitter can add 0-255 bytes of padding. Padding >> beyond that required for encryption algorithm blocksize alignment may >> be used to conceal the actual length of the payload, in support of >> traffic flow confidentiality. However, inclusion of such additional >> padding has adverse bandwidth implications and thus its use should be >> undertaken with care. The Padding field is optional, but all >> implementations MUST support generation and consumption of padding. >> >The ESP draft is wrong. It has a scoping error. The description of >padding is to be left to the individual transforms. See the previous >notes to this list on the implementors' agreement. > >If this is not fixed in the next draft of ESP, I'm sure someone will >suggest a more specific change in wording. > > >> Lastly, RFC1829 states: >> >> Padding >> >> The size of this field is variable. >> >> Prior to encryption, it is filled with unspecified implementation >> dependent (preferably random) values, to align the Pad Length and >> Payload Type fields at an eight octet boundary. >> >> After decryption, it MUST be ignored. >> >> I don't understand how someone can write code to support the padding >> requirements that conform to RFC1829 or the "new" ESP and find that it will >> interoperate with code that is written to follow your new draft. An RFC1829 >> programmer will send the "preferably random" values in for padding and the >> implementor of your new draft will reject the incoming packet for lack of a >> "valid series of integer values". While you don't say exactly what to do in >> this case, it certainly leaves room for various interpretations (read that >> as potential interoperability problems). >> >Hopefully, not everyone will read only the first part of a draft, and >will actually follow and implement the draft in its entirety. > >The values were previously "implementation dependent", which was open to >various interpretations. > >The "preferably random" values turned out to be cryptographically wrong. > >At the request of the persons explicitly named in the Acknowledgements, >the "implementation dependent" values were changed to specified values. >This is not open to various interpretations. > >I realize that you are new to the list, and may have missed the earlier >debates. > >Remembering that you like to use the same technique in multiple venues, >I'll point out that these values are used in PPP DES encryption. And >that non-random values are also specified in RSA's PKCS. > >WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > >
- Perplexed by padding values (was "padding values") Bob Monsour
- Re: Perplexed by padding values (was "padding val… William Allen Simpson