[botan-devel] newbie observations and questions

Patrick Pelletier code at funwithsoftware.org
Sun Apr 22 02:30:33 EDT 2012


I'm a newbie to Botan, but from looking at the code (and implementing  
an engine), I have a few observations and questions.  (Most of these  
observations are based on the 1.10.1 tarball, because I only got  
Monotone working tonight.  But I think these observations are still  
true for the Monotone head.)

I noticed that ARC4::name() and Core_Engine::find_stream_cipher() use  
different naming conventions for ARC4.  find_stream_cipher recognizes  
"ARC4" with an argument, or "RC4_drop" as shorthand for 768.  On the  
other hand, ARC4::name returns "ARC4" if skip is 0, "MARK-4" if skip  
is 256, or "RC4_skip" with an argument for any other skip value.  Why  
the discrepancy?

I might be missing something, but it looks to me like XSalsa20  
requires setting the key again each time before setting a new IV.   
(Unlike regular Salsa20, where the key can be set once, and then the  
IV can be set multiple times.)  This is because Salsa20::set_iv()  
overwrites state[1..4] and state[11..14] (which contain the key) in  
the XSalsa20 case.

In checks/bench.cpp, I noticed that REVERSE_ITERATOR_BUG is defined,  
but not used.

A few typos:

checks/validate.cpp: "expecing" -> "expecting"
src/libstate/init.cpp: "so for" -> "so forth"
src/engine/openssl/ossl_arc4.cpp: "suported" -> "supported"

"reqeust" should probably be "request" (appears twice in  
core_engine.h, and once each in asm_engine.h, simd_engine.h, and  

In Library_State::initialize(), the case for BOTAN_HAS_MUTEX_QT looks  
suspicious, because it looks like a declaration ("mutex_factory  
Qt_Mutex_Factory;"), rather than an assignment like the other cases  
("mutex_factory = new Pthread_Mutex_Factory;").

I believe that the lines in validate.dat of the form "[MyCipher-123  
<EXTENSION>]" actually never do anything, because the code only  
removes "<EXTENSION>" from the end and then tests "MyCipher-123  
" (note the space at the end) which does not exist.  (But since it's  
an extension and isn't required to be present, the test doesn't fail.   
It just means the test is never checked, even if "MyCipher-123" is  
present.)  Either validate.dat needs to have the space removed before  
"<EXTENSION>", or else the code needs to be changed to remove the  
space after "MyCipher-123" when it removes "<EXTENSION>".  (I believe  
the only current uses of <EXTENSION> are for zlib and bzip2, but I ran  
into this when adding tests for Camellia, since in 1.10.1, Camellia  
wasn't implemented in the core, so I had to make the tests optional.)

Even after working around the space issue mentioned above, it isn't  
possible to use <EXTENSION> in CMAC tests, because this happens:

Testing MACs: ...........Exception: Could not find any algorithm named  
ERROR: "CMAC(Camellia-128)" failed test #1

This is because Algorithm_Factory::make_block_cipher throws  
Algorithm_Not_Found, and is called by Core_Engine::find_mac.  find_mac  
should catch the exception and return NULL.  Or, if this is really  
desired, then the testing code should catch the exception and allow it  
when "<EXTENSION>" is present.

In eax_test.cpp, there was a comment that LibTomCrypt's lone Noekeon  
test vector does not match Botan.  I tracked this down, and there are  
actually two reasons for this:

1) LTC uses direct Noekeon (no key schedule), while Botan uses  
indirect Noekeon (key scheduled by encrypting with Noekeon).  See page  
14 of http://gro.noekeon.org/Noekeon-slides.pdf

2) LTC has a bug, where its PI1 and PI2 functions do not match the  
Noekeon specification.

So apparently LTC's "lone test vector" must have been self-generated,  
rather than coming from a third party.

I filed a bug against LibTomCrypt, and submitted a fix:


But it appears that LibTomCrypt is no longer actively maintained.  (No  
activity for 10 months, anyway.)

I wrote some code which can produce Noekeon EAX test vectors suitable  
for Botan, using BouncyCastle:


Also, I've implemented an "engine" for Nettle, analogous to the  
existing one for OpenSSL.  Is this the sort of thing you'd like to  
have contributed to the Botan codebase, or is it more appropriate for  
it to be a separate, add-on project?

The existing OpenSSL engine has three ciphers for Camellia:  
"Camellia-128", "Camellia-192", and "Camellia-256", analogous to the  
three AES ones.  I wrote my Nettle engine using this scheme, to match  
the OpenSSL engine, which is the only Camellia implementation in Botan  
1.10.1.  But, after I pulled down the Monotone head tonight, I saw  
that Botan has its own Camellia implementation now, but it is  
implemented as a single cipher, "Camellia", with variable key size,  
much like how Serpent and Twofish were already done.  Any thoughts on  
which approach is better?

Nettle is the fastest for some algorithms, but not for others:

AES-128 [nettle] 147.22 [openssl] 123.83 [core] 108.59
AES-192 [nettle] 125.06 [openssl] 106.83 [core] 95.84
AES-256 [nettle] 105.04 [openssl] 93.90 [core] 85.72
Blowfish [core] 99.75 [nettle] 94.43 [openssl] 86.60
Camellia-128 [nettle] 131.54
Camellia-192 [nettle] 98.20
Camellia-256 [nettle] 98.19
CAST-128 [nettle] 78.38 [core] 72.98 [openssl] 64.32
DES [core] 58.88 [nettle] 54.63 [openssl] 46.11
RC2 [nettle] 41.87 [openssl] 30.82 [core] 27.74
Serpent [nettle] 84.75 [simd] 84.69 [core] 55.74
TripleDES [core] 20.74 [nettle] 17.88 [openssl] 17.77
Twofish [core] 112.74 [nettle] 107.84
ARC4 [openssl] 183.33 [nettle] 164.45 [core] 90.98
MD2 [nettle] 5.84 [core] 4.94 [openssl] 4.27
MD4 [openssl] 727.84 [core] 575.66 [nettle] 417.97
MD5 [openssl] 452.99 [core] 379.88 [nettle] 311.16
RIPEMD-160 [core] 226.45 [openssl] 163.56 [nettle] 161.32
SHA-160 [nettle] 290.10 [openssl] 277.71 [simd] 270.38 [core] 236.60  
[asm] 219.37
SHA-256 [core] 127.22 [openssl] 109.29 [nettle] 101.40
SHA-384 [core] 195.67 [openssl] 168.69 [nettle] 158.40
SHA-512 [core] 195.69 [openssl] 168.78 [nettle] 158.40


More information about the botan-devel mailing list