Mailing List Archive

"Niels Möller" wrote:

> At the crypto workshop a few months ago, I promised to write up my
> ideas for a low-level crypto library interface. I have a first version
> of that document now, at <URL:
> http://www.lysator.liu.se/~nisse/lsh/doc/crypto-library.txt>.
>
> It also describes an object-oriented interface that can be built on
> top of the low-level interface, and some examples. It's similar to
> (but not exactly the same) the interfaces currently used in lsh.
>
> I hope this is an appropriate place for this. Comments are welcome.
>
> Regards,
> /Niels

Niels,

Thanks for sending this contribution - it was good reading material. Here
are a few comments and thoughts I have about this subject:

I take a slighty different approach in BeeCrypt. I do have a context
structure for every algorithm (even for random generators and hash
functions), but I don't define constants - they make code that uses them
inflexible.

The way I've solved this is by having a table which describes all
algorithms of a certain kind. Every entry in the table describes an
algorithm, has fields that describe its characteristics (including the
name of the algorithm so that the table can be searched), and has
pointers to the actual routines for the algorithm.

For instance my blockcipher structures and table currently look like
this:

typedef void blockCipherParam;

typedef int (*blockCipherSetup )(blockCipherParam*, const uint32*, int,
cipherOperation);
typedef int (*blockCipherSetIV )(blockCipherParam*, const uint32*);
typedef int (*blockCipherEncrypt)(blockCipherParam*, uint32*, const
uint32*);
typedef int (*blockCipherDecrypt)(blockCipherParam*, uint32*, const
uint32*);

typedef struct
{
const char* name;
const unsigned int paramsize; /* in bytes */
const unsigned int blocksize; /* in bytes */
const unsigned int keybitsmin; /* in bits */
const unsigned int keybitsmax; /* in bits */
const unsigned int keybitsinc; /* in bits */
const blockCipherSetup setup;
const blockCipherSetIV setiv;
const blockCipherEncrypt encrypt;
const blockCipherDecrypt decrypt;
const blockMode* mode;
} blockCipher;

static const blockCipher* blockCipherList[] =
{
&blowfish
};

The blowfish structure itself looks like this:

const blockCipher blowfish = {
"Blowfish",
sizeof(blowfishParam),
8,
64,
448,
32,
(const blockCipherSetup) blowfishSetup,
(const blockCipherSetIV) blowfishSetIV,
(const blockCipherEncrypt) blowfishEncrypt,
(const blockCipherDecrypt) blowfishDecrypt,
blowfishModes
};

In this way it is possible to use pretty abstract code, even in C.

For block modes (ECB, CBC, etc.), I have routines that can take a cipher
and its context, and perform the requested operation from a source block
to a destination block. Individual ciphers can have optimized speedups
for each block mode, in addition to the generic code (through the
blockMode pointer, in case you were wondering).

At a later stage I hope to be able to do something similar for assymetric
algorithms. I'll most likely make tables for assymetric ciphers,
signatures, and key agreements.
In the future, I can also make the library more flexible by dynamically
inserting and removing algorithm providers (instead of using the current
static tables).

Offtopic: I'm thinking about starting a new open-source (GPL) project
called 'BeeUtils', of which the first part will be small apps for
computing the cryptographic hash value of a file. Of course the md5sum
utility is available in the GNU textutils, but what about a sha1sum, or
even a sha256sum? Is there a need for utilities that do this?

As above, comments are welcome.

Sincerely,

Bob Deblier
Virtual Unlimited

Bob Deblier <bob@virtual-unlimited.com> writes:

> Thanks for sending this contribution - it was good reading material. Here
> are a few comments and thoughts I have about this subject:

Thanks for reading.

> The way I've solved this is by having a table which describes all
> algorithms of a certain kind.

This is a common approach, I guess (I think both Werner's gnupg,
openssl and several other libraries do that).

In lsh, I also have a table, but at a higher level. I have integer
constants for all algorithms known by my secsh implementation, for
instance ATOM_3DES_CBC, which is installed in the table by something
like

ALIST_SET(algorithms, ATOM_3DES_CBC, make_3des_cbc());

But there's no entry for plain des anywhere. Then I have a
gperf-generated code to map names that occur in protocol messages to
these integer atoms, and a different, more fuzzy, function for mapping
human-supplied names to atoms.

I can build this on top of the low-level interface, and I believe it
should be straight-forward to build a table like yours on top of the
same code. My intention is to make it feasible to share a low-level
library, even between applications and contexts with different ideas
on how to manage and select algorithms.

Some generic functions could perhaps also be added to the low-level
library, like

void gcrypt_cbc_encrypt(void *ctx,
(*encrypt)(void *, unsigned length,
uint8_t *dst, const uint8_t *src),
uint8_t *iv, unsigned block_size,
unsigned length,
uint8_t *dst, const uint8_t *src);

if that seems useful. memxor() should also be part of the library (and
perhaps also a part of glibc, of we can sell that idea to the glibc
folks).

> Offtopic: I'm thinking about starting a new open-source (GPL) project
> called 'BeeUtils', of which the first part will be small apps for
> computing the cryptographic hash value of a file. Of course the md5sum
> utility is available in the GNU textutils, but what about a sha1sum, or
> even a sha256sum? Is there a need for utilities that do this?

My first reaction is that I would rather see those utilities as a part
of text-utils, just like md5sum.

Best regards,
/Niels

On Wed, Dec 13, 2000 at 07:36:25PM +0100, Niels Möller wrote:
> At the crypto workshop a few months ago, I promised to write up my
> ideas for a low-level crypto library interface. I have a first version
> of that document now, at <URL:
> http://www.lysator.liu.se/~nisse/lsh/doc/crypto-library.txt>.
>
Good work!

Now the ob question, what is the gcrypt devel status ?

--
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
[sig out on holidays]

On Thu, 14 Dec 2000, Carlos Morgado wrote:

> Now the ob question, what is the gcrypt devel status ?

Well, I noticed that Niels used gcrypt_something() in his API
description. I am not sure whether this is just an example - I have
found no time to read the description.

libgcrypt (the library from gnupg) is used by gnutls and I am going
to split gnupg into gnupg and the library. I only need to find a
day or so to tinker with the CVS. Development of libgcrypt should
go much faster as soon as it is not anymore closely bound to gnupg.

Werner