• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..03-May-2022-

Makefile.amH A D09-Mar-200289 32

Makefile.inH A D19-Feb-200711.4 KiB405351

README.configH A D09-Mar-2002372 159

README.keyH A D09-Mar-2002472 97

README.xteaH A D09-Mar-2002550 149

example.cH A D09-Mar-20022.7 KiB11965

mcrypt.3H A D08-Mar-200324.3 KiB651505

README.config

1If you want to find the libmcrypt library in other projects
2using autoconf/aclocal, put in your
3
4aclocal.m4:
5 include(libmcrypt.m4)
6
7configure.in:
8 AM_PATH_LIBMCRYPT( 2.4.11,, AC_MSG_ERROR([[*** libmcrypt was not found]]))
9
10
11these macros define LIBMCRYPT_LIBS and LIBMCRYPT_CFLAGS.
12If Libmcrypt version 2.2.x is found then LIBMCRYPT22 is defined,
13otherwise LIBMCRYPT24.
14
15

README.key

1Mcrypt 2.1 was insecure (vulnerable to brute force attack for weak keys)
2because it just used the plainkey as it was given by the user as algorithm's
3key. The solution seems to be a function which tranforms the
4key given by the user to a real -random looking- key.
5
6There are many functions that may convert a password or a passphrase to
7a key. Most of them use hash algorithms. You can find some implementations
8at the libmhash package at: http://mhash.sourceforge.net
9

README.xtea

1
2
3The xTEA algorithm may not be right implemented. There are two different
4behaved implementations, because the specification is not clear. I assumed
5that the C code in the specification is right, so in mcrypt xtea behaves
6exactly as the code shown in the specification. The different approach
7is the code in ftp.funet.fi which seems to be more rational than the
8code in the specification. But since there is no indication of the author of
9that code I decided not to adopt this version, and I assumed that the
10C specification is right.
11
12						Nikos
13
14