FreeSec - NetBSD libcrypt replacement David Burren Release 1.0, March 1994 Document ref: $FreeBSD: src/secure/lib/libcipher/README,v 1.4 1999/08/28 01:30:19 peter Exp $ Document ref: $DragonFly: src/secure/lib/libcipher/README,v 1.2 2003/06/17 04:27:48 dillon Exp $ Description =========== This library is a drop-in replacement for the libcrypt used in U.S. copies of NetBSD, duplicating that library's functionality. A suite of verification and benchmark tools is provided. FreeSec 1.0 is an original implementation of the DES algorithm and the crypt(3) interfaces used in Unix-style operating systems. It was produced in Australia and as such is not covered by U.S. export restrictions (at least for copies that remain outside the U.S.). History ======= An earlier version of the FreeSec library was built using the UFC-crypt package that is distributed as part of the GNU library. UFC-crypt did not support the des_cipher() or des_setkey() functions, nor the new-style crypt with long keys. These were implemented in FreeSec 0.2, but at least one bug remained, where encryption would only succeed if either the salt or the plaintext was zero. Because of its heritage FreeSec 0.2 was covered by the GNU Library Licence. FreeSec 1.0 is an original implementation by myself, and has been tested against the verification suite I'd been using with FreeSec 0.2 (this is not encumbered by any licence). FreeSec 1.0 is covered by a Berkeley-style licence, which better fits into the *BSD hierarchy than the earlier GNU licence. Why should you use FreeSec? =========================== FreeSec is intended as a replacement for the U.S.-only NetBSD libcrypt, to act as a baseline for encryption functionality. Some other packages (such as Eric Young's libdes package) are faster and more complete than FreeSec, but typically have different licencing arrangements. While some applications will justify the use of these packages, the idea here is that everyone should have access to *at least* the functionality of FreeSec. Performance of FreeSec 1.0 ========================== I compare below the performance of three libcrypt implementations. As can be seen, it's between the U.S. library and UFC-crypt. While the performance of FreeSec 1.0 is good enough to keep me happy for now, I hope to improve it in future versions. I was interested to note that while UFC-crypt is faster on a 386, hardware characteristics can have markedly different effects on each implementation. 386DX40, 128k cache | U.S. BSD | FreeSec 1.0 | FreeSec 0.2 CFLAGS=-O2 | | | ========================+===============+===============+================== crypt (alternate keys) | 317 | 341 | 395 crypt/sec | | | ------------------------+---------------+---------------+------------------ crypt (constant key) | 317 | 368 | 436 crypt/sec | | | ------------------------+---------------+---------------+------------------ des_cipher( , , , 1) | 6037 | 7459 | 3343 blocks/sec | | | ------------------------+---------------+---------------+------------------ des_cipher( , , , 25) | 8871 | 9627 | 15926 blocks/sec | | | Notes: The results tabled here are the average over 10 runs. The entry/exit code for FreeSec 0.2's des_cipher() is particularly inefficient, thus the anomalous result for single encryptions. As an experiment using a machine with a larger register set and an obscenely fast CPU, I obtained the following results: 60 MHz R4400 | FreeSec 1.0 | FreeSec 0.2 ========================+================================= crypt (alternate keys) | 2545 | 2702 crypt/sec | | ------------------------+--------------------------------- crypt (constant key) | 2852 | 2981 crypt/sec | | ------------------------+--------------------------------- des_cipher( , , , 1) | 56443 | 21409 blocks/sec | | ------------------------+--------------------------------- des_cipher( , , , 25) | 82531 | 18276 blocks/sec | | Obviously your mileage will vary with your hardware and your compiler...