Features Download

From: Brian M. Carlson <sandals <at> crustytoothpaste.ath.cx>
Subject: Re: Possible packages - seccure
Newsgroups: gmane.linux.debian.devel.audit
Date: Wednesday 2nd August 2006 22:47:00 UTC (over 12 years ago)
On Wed, Aug 02, 2006 at 09:12:13PM +0200, Ulf Harnhammar wrote:
> On Sun, Jul 30, 2006 at 01:51:48PM +0100, James Westby wrote:
> > 2) I have an ITP[3] open for seccure[4]. I would be interested in an
> >    audit of the code.
> I have audited it now. I looked for the normal problems like buffer
> overflows, format string bugs and NULL dereferencing without finding
> any bugs at all. It's all well-written code by someone clueful. I don't
> know very much about cryptography, so I have no idea whether the
> program's encryption is easy to break or not.

I've looked at the underlying primitives, but not their implementation.
In short, if they are actually implemented properly[0], they are

The long version (you can skip this) is that the signature is ECDSA (DSA
over elliptic curve) and the encryption is ECIES (Elliptic Curve
Integrated Encryption Scheme).  Both are based on the Diffie-Hellman
problem, which is what regular DSA is based on.  DSA and Elgamal are
what most people use for signing and encryption in OpenPGP, and they are
presently considered secure.  The benefit to elliptic curve cryptography
is that the keys are smaller and it can be faster.  Instead of
multiplying or exponentiating, you can add or multiply points on the
curve.  The curve is such that adding two points will always produce a
third point on the curve.

The only other concern of mine is the method for creating keys.  If the
underlying curves are the ANSI standard curves, they are secure, but
patented.  That is part of the reason that GnuPG nor the OpenPGP
standard include ECC algorithms.  Someone may want to look at the curves
for the -c option and see if they are the patented ones; David Shaw of
the GnuPG team *might* be able to help you.  You might also ask on
-legal, but I don't know how much they know about ECC patents.

Oh, and hi.  I've been reading for a while, but I just haven't gotten
around to auditing anything lately.  Just for the record, I am not a
cryptographer, but I know enough about cryptography to know how things
work and what problems usually happen with it.  I also write crypto code
on occasion.

[0] This is harder than you think.  I managed to implement either SHA256
or SHA512 such that it passed *all* of the standard testsuites, but due
to a padding problem, it broke on certain messages.  Needless to say,
this was a terribly difficult bug to find, and as soon as I fixed it, I
added an additional (unofficial) test created with GnuPG and OpenSSL.

[1] Secure means not only using good algorithms, but using them
*correctly*.  WEP is basically insecure because instead of using a block
cipher (AES, say), IEEE used a stream cipher (RC4).  You can't really
use an IV (initialization vector, which basically foils certain types of
attacks like the kind used to break WEP) on a stream cipher.  And RC4,
as a stream generator, which you then XOR with the data, has a 37%
chance of producing a 0x01 as the first byte of the keystream and a 12%
chance of producing a 0x03 as the second byte.  This is due to
insufficient mixing of the S-box.

CD: 10ms