Re: Release 1.1 (beta) of my AES implementation

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

Date: Wed, 25 Jun 2003 16:59:31 +0200

Tom St Denis wrote:
>
[snip]
> What I was hinting at is you should break up the code into separate files.

Viewpoints could indeed be different for different persons.
I had the original code in 2 parts, but decided to merge
them for the current release. The idea is that, since the
whole is not huge, space isn't an issue. So, if one has
the ensemble in one header file, say aes.h, then one has
everything there that one needs, whether installation,
demo or actual encryption/decryption. That simplifies the
matter (management) in my view.

> > I suppose there is a misunderstanding here. In the
> > application runs (i.e. not the installation run), no
> > explicit GF multiplication is done. (There is GF
> > multiplication code in the non-optimized version of a
> > function, which is however not actually used.)
>
> Might want to rethink that. Having a smaller/slower variant is not
> always a bad idea. That being said you can trivially speed up the GF
> multiplier without incresing its size too badly.

I see. Yet I am afraid that would not comply with my
'principle' of having as little numerical constants
as (practically) possible. For the additional tables
have to be checked by the user who desires to have
a visual verification of the logic before venturing to
use the software.

> Yes, but including source with #include is a bad idea in general. You
> should really think of writing your code as standalone .C and .H files.

I personally would disagree. As said, I have only cast
an extremely superficial glance at your stuff. (I have
to delay a proper reading of that, for currently I have
unfortunately some rather higher priority personal
matters to deal with.) But how is your library to be
used? I would think that one would do something like
either #include "tomslib.h" or #include "spfunc.h",
where spfunc is a special function in your library.

> Because my code [and LTM too] is thread safe as far as low end stuff is
> concerned. For the curious, the only thread-dangerous functions in LTC
> are the registry functions [e.g. register_cipher] which wouldn't
> normally be called after an application has split into threads.
>
> This means my code can be used in an application that has threads
> without worrying. Your code on the otherhand must have a mutex or
> semaphore on the routine to prevent two threads from using the same buffers.

I guess that my CS knowledge must be quite out of date.
I would think that an application doing encryption/decryption
would, at least in that part, be doing sequential processing.
I don't understand why one would need semaphores at all.

Thanks.

M. K. Shen