OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Crypto Archives: Re: Testvectors

Re: Testvectors

Mok-Kong Shen (mok-kong.shent-online.de)
Sat, 04 Sep 1999 12:34:55 +0200

Jim Gillogly wrote:
>
> M-K Shen wrote:
> > Your sentences are a bit unclear for me. Are you asserting that
> > omission of the intermediate P an IP could lead to errors or are you
> > asserting that keeping these (thus having the original DESs intact)
> > could lead to errors?
>
> Errors are always possible when adapting old code to make new code.
> Tim Dierks pointed out the IP/FP issue. While the operation is
> perfectly well-defined (leave off FP after DES-E, leave off IP
> and FP for DES-D, leave off IP for DES-E), it's quite possible for
> the programmer to screw up and fail to leave off one of them, or
> to have the code leave off too many of them. Other errors that
> have been made in 3DES implementations include accidentally
> doing DED instead of EDE, doing EEE or DDD instead, switching
> the ordering on input and output blocks, perhaps even throwing
> in an endian botch that was handled correctly for the straight
> DES, and probably any number of other possibilities. The three
> keys will typically be handled differently from the 1DES case.
> In short, there will be new code. Much of it will be straightforward,
> but it still needs to be tested.
>
> If you don't test, your program is unlikely to work. Why are you
> having trouble with this concept? Anyone who has written portable,
> interoperable, or commercial code must be familiar with this dictum.

I don't have trouble with this concept. There can be NO debate on
the necessity of through testing in general. However, resources are
limited. One usually expends the majority of resources in testing
units that are most likely to contain bugs. One can't test everything
thoroughly. For a trivial example, one can't never be sure that
the arithmetic unit on one's chip doesn't have design/manufacturing
flaws. But as far as I know one never/seldom tests that, because
a thorough testing would require enormous resources. So there are
economic criteria in play. In the present case, it is certainly quite
simple and cheap to test whether the omission of the pair P-IP is in
order. But I would, if I were very extremely concerned about every
and each single step that could introduce bugs, choose not to venture
to employ that omission and use the original DESs (seriously tested)
as such so that I could have a better feeling of assurance of freedom
of bugs, at the cost of a certain small efficiency of course. As I
said, the piping of the output of one (original) DES to the input of
another (original) DES is -- in my conviction (at variance to the
opinions of Mr. Watt and Mr. Sommerfeld) -- (comparatively) very
unlikely to cause problems, on the assumption of course that the
programmer is disciplined and trustworthy and has attained a certain
level of professional proficiency.

M. K. Shen

This archive was generated by hypermail 2.0b3 on Sat Sep 04 1999 - 07:48:53 CDT