[OT] Re: crypt equivalent for Win32 platform?

From: Michael Winter (M.Winter_at_[no-spam)
Date: 10/23/03 

Date: Thu, 23 Oct 2003 00:42:54 GMT

"Kenjis Kaan" wrote on 22 Oct 03:

> William Ahern wrote:
> > Kenjis Kaan wrote:
> > >> (or google) the folks on comp.unix.programmer why crypt(3)
isn't exactly
> > >> meant to be a generic (or even useful anymore) "encryption"
algorithm.
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > >> - Bill
> > >
> > > Why is it not useful anymore?? why?
> >
> > Alright, I'll bite. I wrote this last night, but decided not to
post. I'm by
> > no means an expert, nor even possibly a novice in cryptography,
but it pains
> > me to see people ignorant of this stuff... ;) Granted, I'm
assuming there
> > that when you say "crypt function", you mean crypt(3), the Unix
interface.
> >
> > crypt(3) is an historic Unix interface. For the most part, its
obsolete.
> > crypt(3) doesn't "encrypt". It is a one-way hash. The historic
> > implementation used DES (a block cipher algorIthm), however the
password was
> > used as the key to encrypt something known (like all zeroes). The
purpose
> > was to keep the user's password, transformed so that a plaintext
password
> > could be matched against the stored transformed password, w/o
having to keep
> > the plaintext password in storage (and so exposed). Indeed, in
Linux's
> > glibc, the latest version can use MD5, a purpose built one-way
hash
> > function, instead of DES.
> >
> > I recommend you read the sci.crypt FAQ first. Playing w/
cryptologic
> > primitives is like playing w/ fire, except it can take a really
long time
> > before you realize you've burned yourself, and by then its way too
late to
> > remedy. Learn what a cipher is, a [one-way, cryptographic] hash,
cipher
> > modes, key transformations, et al. Then consult
comp.unix.programmer and
> > your preferred local Win32 newsgroup for implementations to use.
> >
> > If you then find yourself having problems using one of those
> > implementations, and you think your issue might be pertinent to
standard C,
> > folks here can help. Depending on what you're doing, you often
have to be
> > careful w/ the data types you use (unsigned char vs char, int vs
long, etc).
> > These can make huge differences w/ many crypto implementations,
and its
> > those standard C issues which you'll be able to find quality
answers for in
> > this group. Just the other day I found a bug in Apache's SHA1
implementation
> > which assumed a long was 32-bits, and the effects on my 64-bit
Alpha were
> > interesting to say the least.
>
> You are right crypt(3) is just a hash. But it serves what I need it
> for, which is to hash/dehash a password that the user enters in the
> same way that the unix login prompt process works.

By the very definition of a cryptographic hash, you cannot "de-hash"
anything: a hashing function is not reversable.

> See what I
> currently have is a webserver (apache) that provides services,
however
> I don't want just anyone to use it. So I am having a page that ask
> for (username/password) which I then do a lookup from a RDBMS
database
> for the same fields (username/password), however with the
(password)
> field encrypted using crypt(3). Of course I use another hash key to
> maintain sessions id between pages as http is connectionless. Mind
> you I already got this to work on a unix environment as using the
> function crypt(3) in a C or Perl program is trivial. However on
Win32
> is a different matter.
>
> And now that you mentioned crypt(3) is obsolete this is raising a
RED
> flag and I might now have to do some investigations and relook at
the
> whole architecture.
> I might have to throw all this out and redo it from scratch if
another
> way of achieving the same ends is available. This whole issue of
> authenication/security is much more difficult than I had thought.

If this was going to be ported to other platforms, wouldn't it have
been a good idea to use an independent hashing algorithm? If all you
are doing is storing the hash of a password, hashing a user-supplied
password, then comparing them, can't you simply use something like MD5
or SHA-1? There are plenty of source examples around (of MD5, at
least) and it will be portable (assuming a decent implementation). I
don't really see how such a relatively simple change could really
affect your design, either. This is the basic flow of MD5:

1) Instantiate a context structure
2) Initialise the context
3) Process data (pass the context, data, and data length - call as
many times as necessary)
4) Retreive hash

By the way, this still has nothing to do with Standard C.

Mike 

-- 
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

Relevant Pages

  • Re: [md5] string giving specific hash
    ... What do you mean a genetic algorithm? ... If there is a way of getting md5 to output a hash which is not random ( ... B so that its probability of all decimal digits is increased), ...
    (sci.crypt)
  • Re: SHA-1 vs. triple-DES for password encryption?
    ... be better to use a standard algorithm rather than a home-grown one. ... SHA-1 and 3DES have been reviewed for some time. ... This is where a hash comes in nicely. ... Longer passwords and hashes aid in making the hash much harder to work with. ...
    (SecProg)
  • Re: sort unique
    ... given that a hash table is not ... IMO if the vendor's algorithm does something "obvious", ... function to eliminate keys that hash to the same bucket per some ... strings of random lengths, and two strings are ...
    (comp.lang.lisp)
  • Re: Probabalistic algorithms.
    ... >Hashing is typically just an optimisation. ... all the hash does is guarantee that given some ... >hard to factor the composite into its two prime factors. ... >algorithm that's dfaster than brute force factorisation, ...
    (comp.lang.pascal.delphi.misc)
  • Re: out of memory
    ... read only the smaller file into a hash. ... the smaller file will fit into RAM. ... Depending upon the sorting algorithm this would be Ologor ... put your relevant data into a database and use ...
    (comp.lang.perl.misc)