Thread: Problem with crypt

  1. #1
    Unregistered
    Guest

    Unhappy Problem with crypt

    I'm trying to make a programm that encrypts a string with crypt() using a key and then displays the result.

    Here's what I have so far:

    #include <unistd.h>
    #include <stdio.h>
    #include <string.h>
    int main( int argc, char *argv[])
    {
    char text[] = "text";
    char key[] = "key";
    char result[14];
    strcpy( crypt( text, key), result);
    printf("%s", result);
    return 1;
    }

    Now when I try to compile it I get this with (under linux)
    gcc crypt.c -o crypt -lcrypt
    I get this warning:

    warning: passing arg 1 of `strcpy' makes pointer from integer without a cast

    What am I doing wrong here?

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    Does your compiler support the crypt function? If the function is not defined then most compilers will assume that the return value is int. The warning message implies that crypt (a function that returns char *) is actually returning an int and strcpy is confused.

    -Prelude
    My best code is written with the delete key.

  3. #3
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    I don't know about the function crypt. But it should return a pointer to a string. It seems that crypt returns an int and this int is assumed to be an address.

  4. #4
    Registered User
    Join Date
    Jan 2002
    Location
    Vancouver
    Posts
    2,212
    Can't you just use a custom-made XOR encryption function. They are really simple.

  5. #5
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >They are really simple
    And really worthless, an XOR substitution is frighteningly simple to crack. You might as well just not encrypt at all

    -Prelude
    My best code is written with the delete key.

  6. #6
    Registered User
    Join Date
    Jan 2002
    Location
    Vancouver
    Posts
    2,212
    Thought you could only brute force XOR.

  7. #7
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    Brian is right. XOR-crypting is used in the One Time Pad method and extremely strong. It's strongness is in the fact that each key is a possible key. And that makes One Time Pad theoretical uncrackable. I've once explained why XOR-crypting is strong and gave some examples. Make a search on the board, XOR-crypting has been asked about many times.

  8. #8
    Registered User
    Join Date
    Oct 2001
    Posts
    197
    Hi!
    The disadvantage of the One-Time-Pad is that the key has to have the same length than the message.
    You could generate a rather good key in the following way:
    Code:
    unsigned char *key(int keylength)
    {
      unsigned char key[keylength];
      unsigned int count;
    
      for(count=0;count<keylength;count++) key[count]=rand()*rand()*rand()%256;
    
      return key;
    }
    klausi
    Last edited by klausi; 03-10-2002 at 09:59 AM.
    When I close my eyes nobody can see me...

  9. #9
    Registered User
    Join Date
    Oct 2001
    Posts
    197
    Thought you could only brute force XOR.
    You can´t bruteforce a good xor-encryption with the One-Time-Pad because there are all possibilities possible.

    klausi
    When I close my eyes nobody can see me...

  10. #10
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    >The disadvantage of the One-Time-Pad is that the key has to
    >have the same length than the message.

    It is not really necessary, but it is the most safe way. Usually also redundant data is put between the message's bytes. So then the key is longer than the original message.

    Some theoreticists say that the amount of redundant info should be as long as the message. Perhaps, but if One-Time-Pad applied on a message is uncrackable, is it then necessary to add so much redundant info?

  11. #11
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    OTP is only uncrackable if the key is truly random, otherwise the ciphertext is vulnerable to brute force and cryptanalysis. I said that XOR substitution was weak because just about every case of it that I've seen used pseudorandom numbers generated by rand(). Yes, OTP can be strong, but it isn't often used correctly and because of that tends to be weak.

    -Prelude
    My best code is written with the delete key.

  12. #12
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    I wonder if the key should be truly random, just because each key could be valid. As I stated some time ago, it is possible to have more than one keys that result in a plaint text which can be valid.

    If I have the encrypted text:

    ABCDEFG

    Then I can design many keys, when XOR-ed with the encrypted keys, result in a 'valid' plain text. And this does not only count for small messages, but ofcourse also for very large messages. So I don't think the randomness of the key is relevant.

    Since the length of the key is unknown, you could use a kind of block cipher. Where the message and the random data within it is split up in blocks and a key of the length of the block is used. Do you think it is possible to get the length of a block? I don't think so, just because of the principe "every key can be a valid key".

    By the way, a different disadvantage of OTP is that large keys are required. Second, both sender and receiver need a copy of the key. That's why I would prefer a public key algorithm. But that takes more math to understand.

  13. #13
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    The advantages and disadvantages of cryptographic methods could be argued for years

    >when XOR-ed with the encrypted keys, result in a 'valid' plain text
    A good if very involved method considering that the resulting cipher text would have to be a legitimate message that actually meant something to be of any real use.

    >That's why I would prefer a public key algorithm
    I'll change the algorithm that I use based on how it best suits the situation, but my general preference is Steganography since I consider the hardest messages to crack are ones that attackers don't know exist.

    -Prelude
    My best code is written with the delete key.

  14. #14
    The Artful Lurker Deckard's Avatar
    Join Date
    Jan 2002
    Posts
    633

    Re: Problem with crypt

    Originally posted by Unregistered
    strcpy( crypt( text, key), result);
    There is your problem. The first argument of strcpy() is the destination, not the source. Reversing the order of your arguments will solve your problem.

    Cheers,
    Jason Deckard

  15. #15
    Registered User
    Join Date
    Oct 2001
    Posts
    197
    @Shiro:
    I wouldn´t make any sense if you use a OTP-key more than once (e.g when the key is too short), because it would be very simple to crack, if the message is long enough.

    klausi
    When I close my eyes nobody can see me...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Need help understanding a problem
    By dnguyen1022 in forum C++ Programming
    Replies: 2
    Last Post: 04-29-2009, 04:21 PM
  2. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  3. Someone having same problem with Code Block?
    By ofayto in forum C++ Programming
    Replies: 1
    Last Post: 07-12-2007, 08:38 AM
  4. A question related to strcmp
    By meili100 in forum C++ Programming
    Replies: 6
    Last Post: 07-07-2007, 02:51 PM
  5. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 06:54 PM