tags:

views:

2274

answers:

4

Duplicate of this question.

Hi,

I want to write a small program in C/C++ which reads a small text file, and encrypts it, using a "internal" key. Then I also want to write another small program which can decrypt the encrypted file using internally the same key.

I looked at openSSL site and googled but found not simple example, has somebody ever tried to do this thing?

Thanks

+2  A: 

OpenSSL is specifically concerned with implementing SSL and TLS which are protocols for encrypting data over a network. Since you are just looking to encrypt a file, it is possible to use OpenSSL but not ideal.

Instead, I would use something like BeeCrypt or Crypto++® Library 5.6.0 which both provide examples for their use.

Andrew Austin
+4  A: 

Ideally, you could use an existing tool like ccrypt, but here goes:

#include <openssl/aes.h>

/* ... */


{
  int bytes_read, bytes_written;
  unsigned char indata[AES_BLOCK_SIZE];
  unsigned char outdata[AES_BLOCK_SIZE];

  /* ckey and ivec are the two 128-bits keys necesary to
     en- and recrypt your data.  Note that ckey can be
     192 or 256 bits as well */
  unsigned char ckey[] =  "thiskeyisverybad";
  unsigned char ivec[] = "dontusethisinput";

  /* data structure that contains the key itself */
  AES_KEY key;

  /* set the encryption key */
  AES_set_encrypt_key(ckey, 128, &key);

  int num;

  while (1) {
    bytes_read = fread(indata, 1, AES_BLOCK_SIZE, ifp);

    AES_cfb128_encrypt(indata, outdata, bytes_read, &key, ivec, &num,
       AES_ENCRYPT);

    bytes_written = fwrite(outdata, 1, bytes_read, ofp);
    if (bytes_read < AES_BLOCK_SIZE)
  break;
  }
}

Decryption is done by calling AES_cfb128_encrypt with AES_DECRYPT as the last parameter. Note that this code hasn't been given anything more than the most elementary of testing, and that you really should use proper 8-bits random data for ckey and ivec.

EDIT: It seems AES_cfb128_encrypt accepts data of arbitrary length, so you're not required to encrypt in blocks of AES_BLOCK_SIZE (16) bytes.

Michiel Buddingh'
Some direction from aes help doc, saying that:Not all possible variations of key size and modes of operation are provided by this library. For this reason, and others, applications should use the higher level functions L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> etc., instead of calling the AES functions directly.
solotim
@Michiel Budding': I've used your code and need to initialize int num; to the ivec size for it to work correctly.
Macarse
A: 

Do you require OpenSSL? Or does any sort of encrypting library will work? From your requirments (see Andrew Austin's answer), I believe that gpgme would be a better idea.

Here is a basic example of encrypting data with gpgme.

bortzmeyer
hi, i finally used ideas fromhttp://tldp.org/LDP/LG/issue87/vinayak.htmli downloaded and compiled this source code for encrypting/decrypting a simple text file. Once compiled I do:./blowfish input_file.txt output_enc.txt output_dec.txtand I use the options:1) G for generating a key2) E for encrypting the file, so output_enc.txt is generated3) D for decryptiong output_enc.txt so output_dec.txt is generated,but in the third step I obtain a segmentation fault. A decrypted file is generated but it differs in some characters from the original one.Any ideas?
+8  A: 

Previous answers have pointed you towards how to do what you asked for.

I'd like to add a word on why you probably shouldn't do this.

What you are talking about is called "symmetric encryption" (the same key is used for encrypting and decrypting, as opposed to asymmetric encryption where everything encrypted with one key can only be decrypted by a specific counterpart).

Disassembling an executable to determine a hardcoded key being used is next-to-trivial. That means, anyone who gets his/her hands on one of your executables, ever, can break the encryption of any message ever exchanged.

Unless the application you have in mind is very specific, this means your setup might "look" secure, but isn't. In these cases, it's usually better not to encrypt at all, so that no-one involved falls for that false sense of security...

It's very good you are looking to standard libraries to do the encryption (instead of implementing / creating an algorithm yourself), but the protocoll (how applications, keys, and messages are used and exchanged) is at least as important as the cipher itself. You might want to have your ideas tested by someone dealing in cryptography, to tell you the weaknesses. (I'm sure there's enough of that kind here at StackOverflow. ;-) )

DevSolar
+1 for the good advice. But, unlike what you say, at least two answers suggested NOT to do symmetric encryption (Andrew Austin's and mine).
bortzmeyer
I admit I haven't followed the links to find out what they were about. ;-)
DevSolar
I have to dissent a little (and of course I would); we have no idea what the OP has in mind. If the encryption and decryption are done on different computers, an internal key is secure. If he just wants to play around with the SSL libraries, security is irrelevant.I'll give you +1 for the advice, but "you shouldn't do this" is a bit too strong a summary.
Michiel Buddingh'
Now it's "probably". I had a gut feeling about the OP, but you're right, the statement was a bit strong.
DevSolar