crypt equivalent for Win32 platform?

[Kenjis Kaan]

I would like to use the crypt function in a Win32 (ie. C program using
Visual C++ 6.0 compiler). I wrote a little program to see if it will
link but it didn't. So I guess maybe the function isn't implement or
implemented in a different naming convention. Could someone please
help me or show me another method of doing encryption under Win32?
TIA

 

[Mark A. Odell]

(e-mail address removed) (Kenjis Kaan) wrote in

I would like to use the crypt function in a Win32 (ie. C program using
Visual C++ 6.0 compiler). I wrote a little program to see if it will
link but it didn't. So I guess maybe the function isn't implement or
implemented in a different naming convention. Could someone please
help me or show me another method of doing encryption under Win32?

What is your question about the C language? That is, use of C syntax and
standard C libraries. Or was your question more topical in
comp.sources.wanted?

 

[William Ahern]

I would like to use the crypt function in a Win32 (ie. C program using
Visual C++ 6.0 compiler). I wrote a little program to see if it will
link but it didn't. So I guess maybe the function isn't implement or
implemented in a different naming convention. Could someone please
help me or show me another method of doing encryption under Win32?
TIA

Try a newsgroup specific to your platform (in this case Win32). crypt(3)
isn't ISO C, AFAIK. And while you're at it, read the sci.crypt FAQ, and ask
(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

 

[Kenjis Kaan]

(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?

 

[Alan Balmer]

Why is it not useful anymore?? why?

You should have read the part you snipped: "Try a newsgroup specific
to your platform (in this case Win32). crypt(3)
isn't ISO C,"

In other words, it's off-topic here.

 

[William Ahern]

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.

 

[Kenjis Kaan]

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. 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.

 

[Michael Winter]

on 22 Oct 03:

(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

 

[Glen Herrmannsfeldt]

I would like to use the crypt function in a Win32 (ie. C program using
Visual C++ 6.0 compiler). I wrote a little program to see if it will
link but it didn't. So I guess maybe the function isn't implement or
implemented in a different naming convention. Could someone please
help me or show me another method of doing encryption under Win32?

Find it in one of the open source C implementation.

-- glen