Re: [Diehard] Overlap sum test
From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 09/28/03
- Previous message: Jim Gillogly: "Re: controversial paper"
- In reply to: Douglas A. Gwyn: "Re: [Diehard] Overlap sum test"
- Next in thread: Douglas A. Gwyn: "Re: [Diehard] Overlap sum test"
- Reply: Douglas A. Gwyn: "Re: [Diehard] Overlap sum test"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 28 Sep 2003 00:13:35 +0200
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > (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.
>
> No. When I say "carefully reviewed" I mean carefully
> reviewed. There are a great many people capable of
> studying the source code to an implementation and
> verifying that it accurately implements the
> specification. What you need to do if you're going
> to entrust something very important to a piece of
> software is to ensure that such a review is in fact
> conducted by competent people. You probably have to
> pay them..
I see. Now I am curious of which crypto libraries
or comprehensive packages currently available are
reviewed by independent capable people (with certificates
signed by them that you could see, at least when you pay
the required money.)
>
> > 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.)
>
> It is hard to certify a freeware package that is in a
> constant state of flux. The best approach is to take
> the necessary quality assurance measures during the
> design and implementation of the product, not try to
> assess the result of an uncontrolled development process.
On the other hand, at least a rather high percentage of
those in the public that employ crypto seems to use
freeware. For commercial software, see my doubt above.
>
> To give a small but relevant example: In the production
> of a particular large software system at BRL, we from
> the outset instituted a policy of design review, then
> specification of interfaces for each package (think
> functional grouping of modules), then preparation of
> package tests, and only then implementation of the
> package, with the unit test being automated into the
> build process so that every interface was thoroughly
> tested before the corresponding package implementation
> was added to the project library. Every modification
> of existing code has to pass the same testing. An
> organized and enforced approach like that can maintain a
> very high level of software quality and reliability.
I know that one could craft very high quality software
through rigorously following certain software engineering
principles and applying even program verification
techniques. But it seems that practical constraints
(financial factors etc.) cause such (crypto or non-crypto)
software to be the exception rather than the rule.
>
> > (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.)
>
> I think that if you use quick hacks from amateurs,
> you should not expect high quality in the first place.
You might in fact be right, but I am on the other hand
not yet ready to consider the software I alluded to
as having been done by amateurs, for their codes
are often named and cited in the corresponding field.
(For financial reasons, I haven't looked at parallel
commercial software done by professionals, though.)
M. K. Shen
- Previous message: Jim Gillogly: "Re: controversial paper"
- In reply to: Douglas A. Gwyn: "Re: [Diehard] Overlap sum test"
- Next in thread: Douglas A. Gwyn: "Re: [Diehard] Overlap sum test"
- Reply: Douglas A. Gwyn: "Re: [Diehard] Overlap sum test"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
