Шифрование и дешифрование небольшого файла с использованием openssl

Я хочу написать небольшую программу на C / C ++, которая читает небольшой текстовый файл и шифрует его, используя & quot; внутреннюю & quot; ключ. Затем я также хочу написать еще одну небольшую программу, которая может расшифровать зашифрованный файл, используя тот же ключ.

Я посмотрел на сайт openSSL и погуглил, но нашел не простой пример, кто-нибудь когда-нибудь пытался сделать это?

 enthusiasticgeek14 мая 2012 г., 17:18
Вопрос с похожим примеромstackoverflow.com/questions/3141860/…
 jww15 мая 2015 г., 22:41
Вы должны использоватьEVP_* функции.EVP_* функции используют аппаратное обеспечение, например AES-NI (если доступно). УвидетьEVP Symmetric Encryption and Decryption на OpenSSL вики. На самом деле, вы, вероятно, должны использовать аутентифицированное шифрование, потому что оно обеспечиваетboth конфиденциальность и подлинность. УвидетьEVP Authenticated Encryption and Decryption на OpenSSL вики.

Ответы на вопрос(3)

которые являются протоколами для шифрования данных по сети. Поскольку вы просто хотите зашифровать файл, можно использовать OpenSSL, но это не идеально.

Вместо этого я бы использовал что-то вродеBeeCrypt или жеCrypto ++ & # XAE; Библиотека 5.6.0 которые оба предоставляют примеры для их использования.

 05 июл. 2014 г., 01:24
OpenSSL имеет как память, так и файлBIO's, которые являются абстракцией. Библиотека прекрасно работает с буферами памяти, файловыми буферами, сокетами и другими объектами ввода / вывода. Криптографическая часть библиотеки (libcrypto.a) может использоваться автономно; и часть SSL (libssl.a) построен на основе криптографии.

ccrypt, но здесь идет:

#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);

  /* set where on the 128 bit encrypted block to begin encryption*/
  int num = 0;

  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;
  }
}

Расшифровка осуществляется по телефонуAES_cfb128_encrypt сAES_DECRYPT как последний параметр. Обратите внимание, что этому коду не было дано ничего, кроме самого элементарного тестирования, и что вы действительно должны использовать правильные 8-битные случайные данные для ckey и ivec.

EDIT: Похоже на тоAES_cfb128_encrypt принимает данные произвольной длины, поэтому вам не нужно шифровать их блокамиAES_BLOCK_SIZE (16) байтов.

 18 мар. 2012 г., 00:11
Ваш код segfaults bigtime.
 07 апр. 2015 г., 08:12
Указатели FILE ifp и ofp были опущены. Они должны быть объявлены до цикла while сFILE *ifp = fopen("input_file", "rb"); FILE *ofp = fopen("output_file", "wb");
 22 апр. 2010 г., 00:44
@Michiel Budding & amp ;: Я использовал ваш код и должен инициализировать int num; для размера Ivec для правильной работы.
 17 дек. 2009 г., 08:37
Некоторое руководство от aes помогает doc, говоря, что: Не все возможные изменения размера ключа и режимов работы предоставляются этой библиотекой. По этой и другим причинам приложения должны использовать функции более высокого уровня L & lt; EVP_EncryptInit (3) | EVP_EncryptInit (3) & gt; и т. д. вместо прямого вызова функций AES.

Я хотел бы добавить слово о том, почемуyou probably shouldn't do this.

То, о чем вы говорите, называется «симметричное шифрование». (один и тот же ключ используется для шифрования и дешифрования, в отличие от асимметричного шифрования, где все, зашифрованное одним ключом, может быть дешифровано только конкретным партнером).

Разборка исполняемого файла для определения используемого жестко закодированного ключа является тривиальной задачей. Это означает, что любой, кто получит в свои руки один из ваших исполняемых файлов, может сломать шифрование любого сообщения, которым когда-либо обменивались.

Если приложение, которое вы имеете в виду, не является очень конкретным, это означает, что ваша установка может «выглядеть» безопасный, но не т. В этих случаях обычно лучше вообще не шифровать, так что никто не вовлечен в это ложное чувство безопасности ...

Очень хорошо, что вы используете стандартные библиотеки для шифрования (вместо того, чтобы самостоятельно реализовывать / создавать алгоритм), ноprotocoll (how приложения, ключи и сообщения используются и обмениваются), по крайней мере, так же важно, как и сам шифр. Возможно, вы захотите проверить свои идеи кем-то, кто занимается криптографией, чтобы выявить слабые стороны. (Я уверен, что здесь достаточно в StackOverflow. ;-))

 18 июн. 2009 г., 18:59
Я признаю, что не перешел по ссылкам, чтобы узнать, о чем они. ;-)
 14 нояб. 2012 г., 10:37
@ user93353: Все хорошо, но ОП говорила о «внутреннем». ключ, который пахнет "жестко закодированным".
 05 авг. 2014 г., 08:16
Я так люблю проезжающих вниз голосов на пятилетних ответах ...
 18 июн. 2009 г., 17:59
+1 за хороший совет. Но, в отличие от того, что вы говорите, по крайней мере два ответа предлагали НЕ делать симметричное шифрование (Эндрю Остин и мой).
 18 июн. 2009 г., 22:43
Я должен немного выступить (и, конечно, я бы хотел); мы понятия не имеем, что имеет в виду ФП. Если шифрование и дешифрование выполняются на разных компьютерах, внутренний ключ защищен. Если он просто хочет поиграть с библиотеками SSL, безопасность не имеет значения. Я дам вам +1 за совет, но "вы не должны этого делать". Слишком сильное резюме.

Ваш ответ на вопрос