cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/09/29/13:57:42

Message-Id: <199909291534.SAA03957@ankara.Foo.COM>
From: "S. M. Halloran" <mitch AT duzen DOT com DOT tr>
Organization: User RFC 822- and 1123-compliant
To: djgpp AT delorie DOT com
Date: Wed, 29 Sep 1999 19:39:56 +0200
MIME-Version: 1.0
Subject: Re: Crypt() - CAST
References: <7sqbcg$2ngk$1 AT news DOT gate DOT net>
In-reply-to: <Pine.SUN.3.91.990929101345.11087G-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12)
Reply-To: djgpp AT delorie DOT com

On 29 Sep 99, Eli Zaretskii was found to have commented thusly:

> On Tue, 28 Sep 1999, SCOTT19U.ZIP_GUY wrote:
> 
> >   Actaully there are many C codings of encryption methods out on
> > the net. But many don't work with DJGPP with out special tuning.
> 
> Why is that?  What is special about DJGPP or the encryption code that 
> they don't live well together?

Not that you really need to spend your time hacking a port to DJGPP anyway, 
assuming you need to really hack.  With other Win/DOS, it's adding "#include 
<io.h>" as an alternate condition to "#include <unistd.h>" or other.  Are 
coding cryptographers really writing unportable code?

Anyway, many of the algorithms in the public domain (like the RFCs) are simple 
to code.  I had the RC2 algorithm working with a simple encrypt/decrypt library 
working in very little time (I move small encrypted blocks containing user info 
between Web pages).  I hope to beef up the library even more with other 
algorithms and interfaced with the standardized crypto API (also an RFC), if I 
get the spare time.

The fellow wanting crypt() could probably substitute the use of a MD5 digest 
(in the RFCs) if he doesn't really insist on the true crypt().

Mitch Halloran
Research (Bio)chemist
Duzen Laboratories Group
Ankara       TURKEY

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019