[OT] Re: crypt equivalent for Win32 platform?
From: Michael Winter (M.Winter_at_[no-spam)
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)
> > >> meant to be a generic (or even useful anymore) "encryption"
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > >> - 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
> > that when you say "crypt function", you mean crypt(3), the Unix
> > crypt(3) is an historic Unix interface. For the most part, its
> > crypt(3) doesn't "encrypt". It is a one-way hash. The historic
> > implementation used DES (a block cipher algorIthm), however the
> > used as the key to encrypt something known (like all zeroes). The
> > was to keep the user's password, transformed so that a plaintext
> > could be matched against the stored transformed password, w/o
having to keep
> > the plaintext password in storage (and so exposed). Indeed, in
> > glibc, the latest version can use MD5, a purpose built one-way
> > function, instead of DES.
> > I recommend you read the sci.crypt FAQ first. Playing w/
> > primitives is like playing w/ fire, except it can take a really
> > before you realize you've burned yourself, and by then its way too
> > remedy. Learn what a cipher is, a [one-way, cryptographic] hash,
> > modes, key transformations, et al. Then consult
> > 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
> > 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
> > These can make huge differences w/ many crypto implementations,
> > 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
> > which assumed a long was 32-bits, and the effects on my 64-bit
> > 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,
> 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
> for the same fields (username/password), however with the
> 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
> is a different matter.
> And now that you mentioned crypt(3) is obsolete this is raising a
> flag and I might now have to do some investigations and relook at
> whole architecture.
> I might have to throw all this out and redo it from scratch if
> 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.
-- Michael Winter M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)