Re: [Diehard] Overlap sum test

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 09/27/03


Date: Sat, 27 Sep 2003 09:44:01 +0200


"Douglas A. Gwyn" wrote:
>

> It's not clear what would satisfy you. If the code is available
> and carefully reviewd; if the theory on which it is based is well
> understood; and if the implementations successfuly encipher and
> decipher amongst each other for a wide variety of data files,
> that should give a fairly high degree of confidence.

Let me roughly say what don't satisfy me:

(1) As far as I am aware, 'carefully reviewed' only
means in real life that a software has been out for
a long time and used a lot and apparently many people
have glanced at it. We don't know in general the names
of the experts who have really seriously examined them
(let alone how much effort they have spent on it). If
there could be some institutions giving certificates
of software that are signed by reknown experts, that
would be a nice thing for the common (unknowledgeable)
users. I learned recently that there are FIPS certificates.
I don't yet know about them concretely but anyway I don't
think there would be similar certificates for the large
popular crypto packages as a whole. (There are centres
for validation of compilers. How much these contribute
to the quality of complilers I don't really know. But
I suppose that have such validation is anyway a very
good thing.)

(2) If a software is well designed and has good
documentation to enable anyone (with sufficient
knowledge in the topic and experience in programming) to
rather fluently read the code (even though studying a
huge package would undersatandably take correspondingly
long time), I would say it's o.k., for there presumably
are people who are interested and motivated enough to
spend quite an amount of time to examine it. But, at
least for some very little amount of small pieces of
crypto codes that I happend to have looked at, this
is evidently not the case. I extrapolate from this
experience to conjecture that the large crypto
packages aren't much better. (You might object this.)

M. K. Shen