MIME-Version: 1.0
Return-Path: bluepeak.westend.com!popeye
Return-Path: <popeye@bluepeak.westend.com>
Received: from popeye.bluepeak.westend.com by bluepeak  with smtp
	(Smail3.2 #1) id m11Zdt8-000275C; Fri, 8 Oct 1999 19:33:02 +0200 (MEST)
Received: from genesis for a.kupries
 with Cubic Circle's cucipop (v1.10 1996/09/06) Fri Oct  8 19:27:02 1999
Received: from nl-imail01.cmg.nl (nl-mail-dmz.cmg-gecis.nl [195.109.155.100])
	by genesis.westend.com (8.8.6/8.8.6) with ESMTP id JAA25793
	for <a.kupries@westend.com>; Fri, 8 Oct 1999 09:57:14 +0200 (MET DST)
Received: from nl-amv-route01.cmg.nl (NL-AMV-ROUTE01 [10.16.127.107]) by nl-imail01.cmg.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10)
	id 4H42V585; Fri, 8 Oct 1999 09:53:58 +0200
Received: by NL-AMV-ROUTE01 with Internet Mail Service (5.5.2232.9)
	id <TTN8F4QY>; Fri, 8 Oct 1999 10:00:53 +0200
X-From_: jan.nijtmans@cmg.nl  Fri Oct  8 09:57:30 1999
Message-ID: <39DCDDFD014ED21185C300104BB3F99F795771@NL-ARN-MAIL01>
From: Jan Nijtmans <jan.nijtmans@cmg.nl>
To: Andreas Kupries <a.kupries@westend.com>
Subject: md5
Date: Fri, 8 Oct 1999 10:00:49 +0200
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/mixed;
              boundary="----_=_NextPart_000_01BF1163.3DD17F3C"

------_=_NextPart_000_01BF1163.3DD17F3C
Content-Type: text/plain;
              charset="iso-8859-1"


Currently I'm working to add md5 support to Wrap. MD5 is
rapidly becoming the world standard for code signing. Thereby,
first, I looked at Trf. I don't want Wrap to become dependant
on Trf just for a single hash function, but I also
didn't want to include the MD5 code into Wrap itself. I
now found a solution that could be useful for Trf as well.

I downloaded the latest glibc (2.1.2) source code, in
order to see how it handled md5. The result
pleased me: Modern Linux systems have a libcrypt.so.2.1.x
library, which containts a md5-replacement for crypt
together with all md5-functionality. It is just a tiny separate
library, which can easily be built separately, even on Windows.
As a result, the same approach as zlib can be followed:
If the system doesn't provide a valid libcrypt.so, built
libcrypt.so.2.1.2. This library could be loaded dynamically
only when needed.

The attached zip-file contains:
- source code for the crypt library and two test files,
  extracted from glibc-2.1.2.
- Windows binaries: crypt.dll, md5test.exe and md5c-test.exe,
  all compiled with gcc-2.95. The dll is only 8.5 kByte.
- source code for stpncpy(), extracted from glibc-2.1.2 as well.

I guess this is useful for you as well:
- Trf will become a few kbytes smaller, because MD5
  code doesn't need to be included any more.
- On modern Linux systems (glibc 2.1.x and higher),
  you don't even have to build libcrypt.so. It's already there.
- Trf can provide a new "md5crypt" function, which
  does exactly the same as Trfcrypt's "crypt". Only
  it uses MD5 in stead of DES as the engine, and
  therefore doesn't suffer from the U.S.A. export
  and patent restrictions.

Useful, don't you think? Trf 2.0 is not released
yet, and this would also be a good thing to
introduce in a new major release.

Regards,
--
Jan Nijtmans, CMG Arnhem B.V.
email:   Jan.Nijtmans@cmg.nl


------_=_NextPart_000_01BF1163.3DD17F3C
Content-Disposition: attachment;
	filename="md5.zip"
Content-Location: ATT-0-FE43DAC4517DD311AB3900104BC2DC1B-M
	D5.ZIP
Content-Transfer-Encoding: base64
Content-Type: application/zip;
              name="md5.zip"

[encoded data, 44814 characters]
N1BLBQYAAAAAFAAUANUFAADCewAAAAA=

------_=_NextPart_000_01BF1163.3DD17F3C--
