[FFmpeg-devel] [PATCH] DES en-/decryption

[Aurelien Jacobs]

On Sun, 14 Oct 2007 09:05:03 +0200
Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> Hello,
> On Sun, Oct 14, 2007 at 02:05:36AM +0200, Aurelien Jacobs wrote:
> > On Sat, 13 Oct 2007 22:15:42 +0200
> > Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> [...]
> > > If any of the "Makefile-guys" have some time, maybe you could see if you
> > > can come up with something? I'd expect this could be used in some other
> > > code as well (I hope others agree this would be nice).
> > 
> > I haven't really looked at the code, but isn't it possible to simply
> > generate this table in a des_init() function or something like that ?
> 
> Of course, but then 1) the 256 byte S-box table must be kept 2) it will
> use up RAM that can't simply be swapped out to the binary.

3) the binary will be smaller.
Once again,it all depends on user priorities. Maybe we should really
add CONFIG_HARDCODED_TABLES as suggested by Michael once.

> > > Index: libavutil/des.h
> > > ===================================================================
> > > --- libavutil/des.h	(revision 0)
> > > +++ libavutil/des.h	(revision 0)
> > > @@ -0,0 +1 @@
> > > +uint64_t ff_des_encdec(uint64_t in, uint64_t key, int decrypt);
> > 
> > I think you should add multiple inclusion protection.
> 
> Why? As long as there are only function prototypes there should not be
> any reason to use them.

See Diego's answer. And if nothing else, it would at least be for
consistency. Moreover, this header will probably be used at least
once as a model to create a new header for something else, and
then guards will be missing in this new header.
So even if it's not usefull in itself right now, it's just a matter
of "put it in every new header and never think about it anymore".
It will avoid future problems.

Aurel