Проблемы объединения openssl в качестве консоли и библиотеки - PullRequest
1 голос
/ 24 января 2011

Я хотел бы скрыть текстовую информацию (в моем случае шейдеры GLSL), используемую в качестве строк в программе на C / C ++, поскольку они непосредственно читаются в двоичном файле. Поэтому я подумал о шифровании файлов во время компиляции / сборки и дешифровании данных во время выполнения, чтобы продолжить работу с реконструированными шейдерами.

Однако у меня возникли проблемы с работой openssl на консоли вместе с библиотекой (evp) в программе на Си. Я должен признать, что я ни в коем случае не эксперт в криптографии, но должен заняться этой темой сейчас ...

Вот что я пробовал:

// on the console:
openssl enc -aes-256-cbc -salt -in shader.frag -out shader.frag.enc

// ...

// in the program:

//// read enc file ////     
int lengthIN;
char * buffer_encIN;

ifstream is2;
is2.open( "/Path/To/My/Shader/shader.frag.enc", ios::binary );

// get length of file:
is2.seekg( 0, ios::end );
lengthIN = is2.tellg();
is2.seekg( 0, ios::beg );

// allocate memory:
buffer_encIN = new char[ lengthIN ];

// read data as a block:
is2.read( buffer_encIN, lengthIN );
is2.close();


//// decryption ////

char mykey[EVP_MAX_KEY_LENGTH] = "changeit"; // also tried: unsigned char mykey[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
char iv[EVP_MAX_IV_LENGTH] = "01020304"; // also tried: unsigned char iv[] = {1,2,3,4,5,6,7,8};
int tmp_len = 0, in_len, out_len=0;
EVP_CIPHER_CTX ctx;

in_len = strlen( buffer_encIN );
char * buffer_dec = new char[ in_len ];

// decrypt
EVP_DecryptInit( &ctx, EVP_aes_256_cbc(), (unsigned char *)mykey, (unsigned char *)iv );
EVP_DecryptUpdate( &ctx, (unsigned char *)buffer_dec, &out_len, (unsigned char *)buffer_encIN, in_len );
tmp_len += out_len;
EVP_DecryptFinal( &ctx, (unsigned char *)&buffer_dec[ out_len ], &out_len );

printf( "Output:\n%s\n", buffer_dec );

Я застрял здесь с двумя проблемами. Во-первых, большинство вещей работают хорошо, только если я использую опцию -nosalt, которая неприменима для развертывания. По крайней мере, я получаю EVP_DecryptInit и * Update, чтобы вернуть 1, но * Окончательные результаты в 0: несколько байтов в конце перепутались тогда. Во-вторых, используя полную версию (т. Е. С солью), я не могу все запустить и запустить: (

В двух словах: это правильный подход, и я просто должен сделать свою домашнюю работу (особенно, если дело касается соли / IV;)), или это просто тратить часы и получать не больше защиты, чем применять какую-то схему ROT13 скрыть строку?

Любая помощь и комментарии высоко ценится!
Matthias

1 Ответ

2 голосов
/ 24 января 2011

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

Выполнение ROT13, очевидно, будет проще и предотвратит самые простые атакилюдей, которые просто ищут в ваших файлах «vec3» или тому подобное.

Вопрос, который вам нужно задать себе: кто вы пытаетесь помешать взглянуть на ваш шейдерный источник?Случайный наблюдатель?В этом случае ROT13 может быть достаточно.Опытный реверс-инженер?Тогда ваше внутрипроцессное шифрование не будет представлять собой большую защиту.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...