[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Perplexed by padding values (was "padding values")
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
>
>