crypt equivalent for Win32 platform?

Discussion in 'C Programming' started by Kenjis Kaan, Oct 20, 2003.

  1. Kenjis Kaan

    Kenjis Kaan Guest

    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
    Kenjis Kaan, Oct 20, 2003
    #1
    1. Advertising

  2. (Kenjis Kaan) wrote in
    news::

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

    --
    - Mark ->
    --
    Mark A. Odell, Oct 20, 2003
    #2
    1. Advertising

  3. Kenjis Kaan <> wrote:
    > 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
    William Ahern, Oct 21, 2003
    #3
  4. Kenjis Kaan

    Kenjis Kaan Guest

    > (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?
    Kenjis Kaan, Oct 21, 2003
    #4
  5. Kenjis Kaan

    Alan Balmer Guest

    On 21 Oct 2003 06:23:20 -0700, (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?


    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.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Oct 21, 2003
    #5
  6. 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.
    William Ahern, Oct 21, 2003
    #6
  7. Kenjis Kaan

    Kenjis Kaan Guest

    William Ahern <william@wilbur.25thandClement.com> wrote in message news:<f22g61-665.ln1@wilbur.25thandClement.com>...
    > 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. 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.
    Kenjis Kaan, Oct 22, 2003
    #7
  8. [OT] Re: crypt equivalent for Win32 platform?

    "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)
    Michael Winter, Oct 23, 2003
    #8
  9. "Kenjis Kaan" <> wrote in message
    news:...
    > 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
    Glen Herrmannsfeldt, Oct 24, 2003
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. AdrianK
    Replies:
    0
    Views:
    1,533
    AdrianK
    Jul 9, 2003
  2. jcc
    Replies:
    15
    Views:
    4,698
    Nigel Wade
    May 12, 2006
  3. Cosmia Luna
    Replies:
    4
    Views:
    327
    Cosmia Luna
    Mar 11, 2012
  4. ChrisO
    Replies:
    9
    Views:
    172
    A. Sinan Unur
    Aug 13, 2004
  5. asg

    de-crypt... crypt

    asg, Dec 23, 2005, in forum: Perl Misc
    Replies:
    3
    Views:
    127
Loading...

Share This Page