Subject: Re: Possible packages - seccure Newsgroups: gmane.linux.debian.devel.audit Date: Wednesday 2nd August 2006 22:47:00 UTC (over 10 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 secure[1]. 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. -- ($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__ M961H |
|||