12
$\begingroup$

Wikipedia mentions ISO10126 Padding has been withdrawn, but doesn't say why. Also there were no news reports about this, as far as I can see.

Why was it withdrawn? Are there security flaws? Is there maybe a new version?

|improve this question
$\endgroup$
11
$\begingroup$

Indeed, ISO 10126-1:1991 and ISO 10126-2:1991 titled Banking -- Procedures for message encipherment (wholesale) have been withdrawn circa 2007.

The padding specified by ISO 10126 was adding random until the message has length 7 (mod 8) bytes, then adding a byte coding the number of bytes added (including that byte), making the length 0 (mod 8) and suitable for DEA/DES block encryption. The rationale for adding a little randomness is dubious at best; it creates a subliminal channel, for no clear advantage.

I conjecture that the rationale of the withdrawal is not the padding algorithm, but rather the use of single-DEA/DES (56 bit key), which is clearly obsolete and insecure; and availability of other standards for the same purpose.

|improve this answer
$\endgroup$
  • $\begingroup$ If I remember correctly, the standard does not even specify random bytes, but bytes which can have any value. I can look it up at work if anybody is interested. As the receiver has no way to check for randomness, it does not make much difference though. Note that PKCS 5/7 padding is compatible when sending bytes. Of course, you cannot asume PKCS 5/7 padding when receiving bytes as validating any padding byte except the last one may fail. $\endgroup$ – Maarten - reinstate Monica♦ Feb 25 '12 at 14:36
  • $\begingroup$ Thank you for your reply. What do you mean by 'The rationale .. is dubious at best'? Does it have any drawbacks compared to PKCS5? $\endgroup$ – Dexter Feb 26 '12 at 0:25
  • $\begingroup$ @Dexter: I mean that arguably, the benefit of having some random/unspecified bytes added (depriving an attacker of knowledge on plaintext) is outweighed by the drawbacks. In particular, these bytes could become (malignantly or by accident) a subliminal channel leaking sensitive information, e.g. the key, some or some of the plaintext. $\endgroup$ – fgrieu Feb 26 '12 at 21:21
  • $\begingroup$ I'm intrigued by this, wouldn't the fact that two identical plain-texts will have the identical cipher-texts leak information too? (the fact that they are identical) Or should this simply be combated by perturbing the message? $\endgroup$ – falstro Feb 14 '14 at 8:09
  • $\begingroup$ @roe: known plaintext is to be assumed anyway in the context of use of the ISO 10126 standards; therefore there can't be much danger is adding a little more. On the other hand there IS danger in sending nobody-cared-to-check-what-exactly out in the wild. $\endgroup$ – fgrieu Feb 14 '14 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.