From lloyd at randombit.net Wed Aug 1 09:21:45 2007
From: lloyd at randombit.net (Jack Lloyd)
Date: Wed, 1 Aug 2007 09:21:45 -0400
Subject: [Botan-devel] Re: Additional algorithms
In-Reply-To: <46ADB16B.2060502@flexsecure.de>
References: <46ADB16B.2060502@flexsecure.de>
Message-ID: <20070801132145.GY13607@randombit.net>
Hello Manual,
[CC'ing to the developers list due to this perhaps being of wider
interest.]
> Do you have planned to implement or have any additional
> implementation suggestions for the following algorithms?: hash
> algorithms SHA-224
I had not planned on implementing it, because I don't feel it is a
useful algorithm. It is just a weakened form of SHA-256 that exists
only because NIST wanted there to be a hash function that matched the
security level of each NIST approved cipher: SHA-1 and Skipjack,
SHA-256 and AES-128, SHA-384 for AES-192, SHA-512 for AES-256, and
finally SHA-224 for 3-key TripleDES (2^112 strength against well known
man-in-the-middle keysearch techniques).
That said, an implementation of SHA-224 would be trivial to do using
the same code-sharing technique as is currently used with SHA-384 and
SHA-512.
> random number generators
> BBS
This would be fairly easy using the existing big integer code. The
prime generation routines support generating primes of the form needed
for Blum integers. It would make the most sense to do it in the
wrapper style of the X9 PRNG (since BBS on its own does not specify
how to generate the initial seed value).
> SHA1PRNG
I assume you are referring to the algorithm used in Java's JCE? I have
only seen decompiled code (decompiled by a JVM decompiler that was
known to produce bad code on a regular basis), so I can't comment on
much from an implementation perpsective. From my vague memory of the
algorithm I would guess it would be a hundred lines of code.
In general I am not too interested in adding new PRNGs, because
compatability concerns don't exist: in fact if you could distinguish
between two different cryptographically strong random number
generators (CSRNG), it would mean one of them had a serious flaw
(since if you can tell the difference in any way, that means you can
predict patterns in the outputs of one of them).
> macs
> CBC-MAC
Pretty trivial to implement, but CBC-MAC is very insecure. Do you need
this for a new system, or backwards compatability? For a cipher-based
MAC in new systems, a much better alternative is CMAC. CMAC is a
NIST-approved algorithm that can use any block cipher and is fixes the
known flaws in CBC-MAC.
> digital signatures
> ECDSA
> key agreement
> ECKAEG
I've had ECDSA and ECDH in mind for quite a while (probably only over
GF(p) due to patent problems I perceive in GF(2^n)-based ECC). It's
just been a matter of time. Also I haven't heard much about interest
in it, even after polling the list once or twice (though probably most
people looking for ECC in Botan look, see it's not there and go
download Crypto++).
I am not familiar with ECKAEG, could you provide a reference?
Regards,
Jack