Сейчас на форуме: laslo, UniSoft, bartolomeo (+6 невидимых)

 eXeL@B —› Программирование —› Быстрый алгоритм потокового шифрования
Посл.ответ Сообщение


Ранг: 793.4 (! !), 568thx
Активность: 0.74↘0
Статус: Участник
Шаман

 Создано: 14 ноября 2011 13:34
· Личное сообщение · #1

Есть софт, который очень быстро оперирует некоторыми данными и каждые 10 секунд перезаписывает их в файле-состоянии, для того, чтобы можно было продолжить обрабатывать данные с последнего состояния. Размер данных ~2mb. Требуется шифровать данные перед сбросом в файл. Требование - шифрование должно быть максимально быстрым. Шифр должен быть устойчивым к подбору гаммы (данные - фиксированная таблица) и иметь хорошую стойкость к подбору ключа (хотя бы 6 месяцев на взлом).

Кто, что посоветует?

-----
Yann Tiersen best and do not fuck


Ранг: 1053.6 (!!!!), 1078thx
Активность: 1.06↘0.81
Статус: Участник

 Создано: 14 ноября 2011 13:37 · Поправил: reversecode
· Личное сообщение · #2

truecrypt, execrypt на уровне ядра шифруют дисковые данные - думаю можно считать быстрыми?
обычно там AES, хотя есть и другие глянь в соурсы
rtp реалайм видео аудио тоже AES



Ранг: 369.8 (мудрец), 400thx
Активность: 0.39↘0
Статус: Участник

 Создано: 14 ноября 2011 13:41
· Личное сообщение · #3

PE_Kill пишет:
Кто, что посоветует?
AES128 в режиме CTR. Начальное значение счетчика случайное и записывается в начале файла перед данными. Проще всего реализовать через CryptoAPI или CNG (на Vista+), последний еще поддерживает аппаратное шифрование.

PE_Kill пишет:
Требование - шифрование должно быть максимально быстрым.
Особых требований к скорости я тут не увидел. Для шифрования 2мб данных раз в 10 секунд подойдет любой шифр. Впрочем аппаратный AES будет быстрее всего другого в разы.

-----
PGP key <0x1B6A24550F33E44A>

Ранг: 0.0 (гость)
Активность: 0.25↘0
Статус: Участник

 Создано: 14 ноября 2011 13:42 · Поправил: F_a_u_s_t
· Личное сообщение · #4

PE_Kill
У меня знакомый AES юзает в похожем тз,правда по времене у него запас больше сикунд на 15,а так фиг его знает в крипто не шарю.
Add:
Сорри,пока писал ntldr ответил.



Ранг: 6.0 (гость), 25thx
Активность: 0.01↘0
Статус: Участник

 Создано: 14 ноября 2011 13:49
· Личное сообщение · #5

VMPC ("Variably Modified Permutation Composition") - улучшенный вариант RC4. программно прост и шустр.



Ранг: 369.8 (мудрец), 400thx
Активность: 0.39↘0
Статус: Участник

 Создано: 14 ноября 2011 13:57
· Личное сообщение · #6

Fedonin пишет:
VMPC ("Variably Modified Permutation Composition") - улучшенный вариант RC4. программно прост и шустр.
Так как требований к стойкости тоже нет, ваш вариант пойдет. А если ТЗ дополнить требованием компактной и независимой от API реализации, то это отличный выбор.
Только дополню: вектор инициализации должен быть разным и храниться с данными, иначе любой потоковый шифр тривиально взламывается. Уникальный вектор инициализации можно получить соединив счетчик операций шифрования с меткой времени, а лучше от криптостойкого RNG (если он уже есть в проекте).

-----
PGP key <0x1B6A24550F33E44A>


Ранг: 793.4 (! !), 568thx
Активность: 0.74↘0
Статус: Участник
Шаман

 Создано: 14 ноября 2011 14:18 · Поправил: PE_Kill
· Личное сообщение · #7

Во понаписали.

OS - WinXP с кастомным набором библиотек, т.е. шифрования может не быть.

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

Fedonin пишет:
VMPC ("Variably Modified Permutation Composition")
Если знать зашифрованые данные получить гамму не выйдет как в обычном RC4?

ntldr пишет:
Так как требований к стойкости тоже нет, ваш вариант пойдет.
Единственное требование - зная алго шифрования и имея на руках файл - невозможно было его расшифровать минимум за 6 месяцев. Парк машин для атаки ВЕСЬМА ограничен.

-----
Yann Tiersen best and do not fuck

Ранг: 6.0 (гость), 25thx
Активность: 0.01↘0
Статус: Участник

 Создано: 14 ноября 2011 14:29
· Личное сообщение · #8

PE_Kill пишет:
Если знать зашифрованые данные получить гамму не выйдет как в обычном RC4?

Не выйдет, если используем уникальный вектор инициализации (относится ко всем потоковым шифрам) для каждого зашифрованного потока. Здесь ntldr прав.



Ранг: 369.8 (мудрец), 400thx
Активность: 0.39↘0
Статус: Участник

 Создано: 14 ноября 2011 14:30
· Личное сообщение · #9

PE_Kill пишет:
Если знать зашифрованые данные получить гамму не выйдет как в обычном RC4?
Если знать зашифрованные данные, получить гамму можно для любого потокового шифра, на то он и потоковый шифр. Из этого следует основное и строго обязательное правило использования потоковых шифров: никогда не шифровать два потока с одним набором ключевых параметров. Набор ключевых параметров у разных шифров может быть разный, AES-CTR принимает на вход ключ и начальное значение счетчика, VMPC принимает ключ и вектор инициализации, RC4 только ключ (но произвольной длины).
Т.е. у вас при каждом шифровании должен генерироваться уникальный входной параметр (начальное значение счетчика, вектор инициализации или дополнительная часть ключа), который хранится с зашифрованными данными (этот параметр не секретен, но должен обязательно быть уникальным). Таким образом у вас будет каждый раз разная гамма.

PE_Kill пишет:
Единственное требование - зная алго шифрования и имея на руках файл - невозможно было его расшифровать минимум за 6 месяцев.
Насчет стойкости VMPC хз, AES точно пойдет, RC4 точно не нужно использовать.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: DimitarSerg


Ранг: 793.4 (! !), 568thx
Активность: 0.74↘0
Статус: Участник
Шаман

 Создано: 15 ноября 2011 11:18
· Личное сообщение · #10

Ну в принципе понял, алго почитал. Теперь такой вопрос. Пока непонятно с носителем ключа, но есть вероятность, что доступно будет лишь 8 байт. Если получится так, то какая схема получения ключа из этих 8 байт будет наиболее удачной. Например взять 100 000 раз SHA256(&MD5(&Buff8Bytes)) или еще как. Время на получение ключа до 5 секунд.

-----
Yann Tiersen best and do not fuck

Ранг: 369.8 (мудрец), 400thx
Активность: 0.39↘0
Статус: Участник

 Создано: 15 ноября 2011 16:20
· Личное сообщение · #11

PE_Kill пишет:
Пока непонятно с носителем ключа, но есть вероятность, что доступно будет лишь 8 байт.
Маловато... Изыщите хотя-бы 10 байт, и для ваших требований к стойкости замедлять получение ключа не понадобится.

PE_Kill пишет:
Если получится так, то какая схема получения ключа из этих 8 байт будет наиболее удачной. Например взять 100 000 раз SHA256(&MD5(&Buff8Bytes)) или еще как. Время на получение ключа до 5 секунд.
Для таких вещей есть стандарт pkdbf2 (пример использования смотрите в исходниках DiskCryptor).

Но ваш случай особенный, тут надо вытягивать стойкость практически из ничего. Я бы рекомендовал сделать невозможным брут на видеокартах, добавив операцию по динамически генерируемой таблице размером > 64к внутрь цикла. На видеокарте такое будет брутиться медленнее чем на CPU.

UPD: набросал реализацию предложенного алгоритма:
Code:
  1. void expandKey(BYTE salt[16], BYTE key_in[8], BYTE key_out[16])
  2. {
  3.          md5_ctx md5;
  4.          WORD    antiVidTab[65536]; // 128к это больше локальной памяти на любой видеокарте
  5.          BYTE    lastHash[MD5_DIGEST_SIZE];
  6.          int     i, j;
  7.  
  8.          MD5Init(&md5);
  9.          MD5Update(&md5, salt, 16);
  10.          MD5Update(&md5, key_in, 8);
  11.          MD5Final(lastHash, &md5);
  12.  
  13.          for (i = 0; i < sizeof(antiVidTab) / MD5_DIGEST_SIZE; i++)
  14.          {
  15.                  MD5Init(&md5);
  16.                  MD5Update(&md5, lastHash, MD5_DIGEST_SIZE);
  17.                  MD5Update(&md5, &i, sizeof(i));
  18.                  MD5Final((BYTE*)antiVidTab + i*MD5_DIGEST_SIZE, &md5);
  19.          }
  20.          for (i = 0; i < 1000000; i++)
  21.          {
  22.                  MD5Init(&md5);
  23.                  MD5Update(&md5, salt, 16);
  24.                  MD5Update(&md5, key_in, 8);
  25.                  MD5Update(&md5, lastHash, MD5_DIGEST_SIZE);
  26.                  MD5Update(&md5, &i, sizeof(i));
  27.                  MD5Final(lastHash, &md5);
  28.  
  29.                  for (j = 0; j < MD5_DIGEST_SIZE / sizeof(WORD); j++)
  30.                  {
  31.                         // видеокарты загибаются на случайном доступе в некешируемую память
  32.                         ((PWORD)lastHash)[j] ^= antiVidTab[((PWORD)lastHash)[j]];
  33.                  }
  34.          }
  35.          memcpy(key_out, lastHash, 16);
  36. }
  37.  
  38. int main(int argc, char** argv[])
  39. {
  40.          BYTE salt[16] = {0}; /* salt нужен для защиты от Rainbow tables,
  41.                                           должен быть уникальным для каждой реализации, а лучше для каждого ключа */
  42.          BYTE in[8] = { 0, 1, 2, 3, 4, 5, 6, 7 }; /* 8 байт на основе которых генерится ключ */
  43.          BYTE out[16]; /* выходной 16 байтный ключ */
  44.          int  i;
  45.  
  46.          expandKey(salt, in, out);
  47.  
  48.          for (i = 0; i < 16; i++) printf("%0.2x", out[i]);
  49.          _getch();
  50.  
  51.          return 0;
  52. }


-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: Isaev


Ранг: 793.4 (! !), 568thx
Активность: 0.74↘0
Статус: Участник
Шаман

 Создано: 15 ноября 2011 18:40
· Личное сообщение · #12

От видеокарты можно не защищаться. Дело в том, что я знаю тех, кто будет ломать. Для них это слишком сложно. Шифрование xor buf[i], const они ломали 8 дней, а требование в 6 месяцев я взял на всякий случай, вдруг привлекут "спецов".

-----
Yann Tiersen best and do not fuck


Ранг: 756.3 (! !), 113thx
Активность: 0.61↘0.05
Статус: Участник
Student

 Создано: 01 декабря 2011 01:04
· Личное сообщение · #13

PE_Kill пишет:
Шифрование xor buf[i], const они ломали 8 дней
при таком подходе им и rc4 никогда не победить

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh


Ранг: 793.4 (! !), 568thx
Активность: 0.74↘0
Статус: Участник
Шаман

 Создано: 01 декабря 2011 05:13
· Личное сообщение · #14

Isaev пишет:
при таком подходе им и rc4 никогда не победить

PE_Kill пишет:
а требование в 6 месяцев я взял на всякий случай, вдруг привлекут "спецов".
Но GPU для них всё равно слишком сложно, да и ресурсов таких у них нет.

-----
Yann Tiersen best and do not fuck

Ранг: 37.1 (посетитель), 11thx
Активность: 0.03↘0
Статус: Участник

 Создано: 02 декабря 2011 21:10 · Поправил: Promix_17
· Личное сообщение · #15

Есть такой алгоритм поточного шифрования - SEAL, всегда его использую Длина ключа - 160 бит, скорость шифрования — примерно 4 машинных такта на байт текста.
Реализация на С: http://cartman-cipher.narod.ru/mirror/seal3.c


 eXeL@B —› Программирование —› Быстрый алгоритм потокового шифрования
:: Ваш ответ
Жирный  Курсив  Подчеркнутый  Перечеркнутый  {mpf5}  Код  Вставить ссылку 
:s1: :s2: :s3: :s4: :s5: :s6: :s7: :s8: :s9: :s10: :s11: :s12: :s13: :s14: :s15: :s16:


Максимальный размер аттача: 500KB.
Ваш логин: german1505 » Выход » ЛС
   Для печати Для печати