Простые алгоритмы шифрования

Всем привет!

Подскажите, плиз, простые в реализации, но более или менее надёжные алгоритмы шифрования, которые можно уместить в несколько (скажем, пару десятков) строк. Более или менее надёжные – в том смысле, чтобы сходу сложно было понять что там было (даже если были нули и даже имея пароль).

Ну, например.
Делаем из пароля хэш (алгоритмы, кстати, тоже интересуют). Ну скажем, xor-им все символы пароля, сдвигая предыдущий результат на 7 бит через rol, чтобы получить (DWORD).
Берём этот хэш + хэш оригинальных данных (чтобы при изменении исходника даже на бит результат кодирования был разным) в качестве "соли" для ГПСЧ (можно ещё добавить какую-то случайную константу, которая будет храниться вместе с зашифрованными данными). И далее xor-им нужные данные с очередным псевдослучайным числом + с паролем по кругу.

Может, что-то поинтереснее есть?

Ещё хотелось бы, чтобы при изменении зашифрованного исходника на бит результат расшифровки полностью менялся.
Спасибо за идеи заранее

 

Если самопальное и убер ненадежное, но короткое, то самое простое это простенький самопальный поточный шифр:

Щас будет убер небезопасное, но короткое описание шифра, хоть и брутфорсится такое легко.

Криптографам дальше не читать у самого кровь из глаз

Берется некоторый начальный 32-бит ключ, который пихается в сишный srand

далее каждую итерацию генерируется через rand байт, который ксорится с i-м байтом шифруемой строки.

Конец.

Шифр 3 строки кода:

Код (C):

1.   srand(key);
2.    for (int i = 0; i < len; i++)
3.      str[i] ^= rand() % 255

Не благодари xD xD xD

А так rc4 можно уместить в 10 строк кода, без учета деривации ключа в структуру внутреннюю

Код (C):

1. void rc4_crypt(unsigned char *s, unsigned char *Data, unsigned long Len)
2. {
3.     int i = 0, j = 0, t = 0;
4.     unsigned long k = 0;
5.     unsigned char tmp;
6.     for (k = 0; k<Len; k++) {
7.         i = (i + 1) % 256;
8.         j = (j + s[i]) % 256;
9.         tmp = s[i];
10.         s[i] = s[j];
11.         s[j] = tmp;
12.         t = (s[i] + s[j]) % 256;
13.         Data[k] ^= s[t];
14.     }
15. }

но он ненадежный, ломается легко т.к не юзает nonce.

Это тебе нужен блочный шифр в CBC режиме, либо поточный с IV вектором. Можешь в пример выше добавить IV это не трудно, 1-2 строки кода. Я просто опаздываю, погугли че это такое

Из криптостойких смотри в сторону AES/Serpent/Magma в CBC режиме, либо поточные Salsa20/20, Salsa20/12, ChaCha

Или вот, признан самым простым и криптостойким: https://ru.wikipedia.org/wiki/Trivium_(шифр)

 

Чем меньше строк - тем меньше стойкость(так как меньше итераций). Можно использовать самопальные с сомнительной стойкостью, вернее нестойкие(xor займёт меньше всего строк, или свой алгоритм на вложенных сетях Фейстеля, как криптостойкий алго MІSTY1 могу посоветовать, но там кода "много"), или более-менее пригодные алгоритмы если шифровать одним ключом будете < 100 файлов(улучшенные варианты TEA, например XXTEA или Raiden).

Ну, если вы имея пароль не можете расшифровать файл то от такой шифровки нет никакого смысла.

Криптостойкий хеш это SHA-256(Keccak если не ошибаюсь), для вашей цели нужен не просто гпсч а криптографически стойкий гпсч(можете загуглить, реализации есть), в вашей реализации, если данные ксорятся с гпсч а случайная константа хранится с зашифрованными данными в открытом виде, то мы приходим к простому ксору(даже если взять криптостойкий алгоритм, и его результат ключа со случайными данными ксорить с оригинальным текстом, то на выходе мы получим простой ксор текста с данными).

Это вам нужен алгоритм со строгим лавинным эффектом(сейчас разрабатываю такой на основе ARX, но никакой криптостойкости тут нет, просто изменение данных).

Всё вышеописанное(под ваши требования) делает Rijndael с ключом в 256 бит(криптостоек, быстр, лавинный эффект присутствует), но кода там много нужно.

 

Я говорю о том, чтобы имея пароль было весьма сложно понять алгоритм.

 

Стойкость алгоритма не должна определятся его секретностью, иначе это плохой алгоритм. Если же вы имеете ввиду "атаку на связанных ключах" берите алгоритм который будет приемлим для вас(AES-256 устойчив к этой атаке, но если у вас мало файлов для шифровки то берите TEA, его запас прочности - 200 пар открытый/закрытый текст, этого конечно очень мало, но может вам хватит). Если надумаете улучшить свой собственный алгоритм, посмотрите книгу по ARX (https://wasm.in/threads/arx-shifry-i-ix-kriptoanaliz.32792/).

 

zerodawn, а если мы шифруем блоки данных с помощью Salsa20 (т.е. килобайт зашифровали, пошли дальше), следующий блок зависит от предыдущего?
Или два одинаковых блока будут одинаково зашифрованы?

 

Jin X вам нужно почитать вот это https://ru.wikipedia.org/wiki/Режим_шифрования
и то что вы говорите это гаммирование, самый простой вариант это CBC

 

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

А так два одинаковых байта будут пошифрованы по разному. Во время шифрования генерируется гамма, которая ксорится с открытым текстом. То есть результат шифрования зависит от позиции байта в исходном открытом тексте и от комбинации (key, nonce). Именно поэтому стоит следить, чтобы никогда пара (key, nonce) не повторялась. Иначе можно восстановить исходный ключ.

Короче, если открытый текст 000000000000000000000000000000000000000 как бы ты его не шифровал всегда получишь разный текст, при условии, что пара (ключ, nonce) не повторяется.
P.S. В официальном api референсе для сальсы есть функция encrypt_blocks. Это просто делается паддинг и шифруется потоком. Это совсем не те блоки, что в блочном шифре, но благодаря такому подгону можно реализовать режим сцепления блоков, раз уж пугает возможность повторения одного текста. Но я не советую, т.к xor сам с собой дает черти что.

 

Вопрос верный. Больше не пишите таких глуппостей, на первый раз прощаем.

 

Ещё можно перемешивание использовать, где-то у меня валялся эффективный алгоритм перемешивания.

 

Пруфы, что в поточных шифрах есть блоки, тогда извинюсь. Или пруфов не будет?

 

меня всегда смешат эти рассказы про итерации Друзья, усё дико-дико просто: сжимаем файло и шифруем, а заголовок сжатого архива перемещаем куда-нть в глубину файла (по ключу). можно заголовок дажь немного покоцать и восстанавливать его брутом.

 

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

cursor=i%key_size
tmp[cursor]=plaintext[cursor]
nxt=(cursor+1)%key_size
key[nxt]^=tmp[cursor]
plaintext[cursor]+=key[cursor]

 

В таком случае, я все так и написал, а господину Pavia следует разуть глаза и прочитать дальше, либо научиться верно использовать цитирование, если его ответ был адресован в другое место сообщения.

 

Локер пилите?)
См. в сторону salsa20

 

betrayer, уже не пишу

 

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

TEA XTEA

--- Сообщение объединено, 4 окт 2018 ---

Компанией Intel в 2008 г. были предложены новые команды для x86 архитектуры, которые добавили поддержку на аппаратном уровне симметричного алгоритма шифрование AES(Advanced Encryption Standard). На данный момент AES — один из самых популярных алгоритмов блочного шифрования.

Оно содержит в себе следующие инструкции:

• AESENC — Выполнить один раунд шифрования AES,
• AESENCLAST- Выполнить последний раунд шифрования AES,
• AESDEC — Выполнить один раунд расшифрования AES,
• AESDECLAST — Выполнить последний раунд расшифрования AES,
• AESKEYGENASSIST — Поспособствовать в генерации раундового ключа AES,
• AESIMC — Обратный Mix Columns.

--- Сообщение объединено, 4 окт 2018 ---

mov eax,0x00000001;
CPUID;
test ecx,0x2000000;
je L_no_AES;

aesenc xmm1, xmm2 ;
aesenclast xmm1, xmm3;

--- Сообщение объединено, 4 окт 2018 ---

https://software.intel.com/sites/default/files/article/165683/aes-wp-2012-09-22-v01.pdf

--- Сообщение объединено, 5 окт 2018 ---

Как советуют профи не нужно придумывать самому алгоритмы шифрования. Самопал ВСЕГДА будет хуже уже готовых алгоритмов.
Если вы не спец в криптографии.
Поэтому советуют использовать готовый криптопримитив.
В вашем случае самые простые ...компактные и быстрые будут:

Блочные TEA XTEA XXTEA.
Потоковый RC2

AES- он сложный но спасает его аппаратная реализация в процах.
Что позволяет делать компактный код и высокую скорость шифрования до 800 Мб/c в однопотоке.

Как вариант можно использовать WinAPI

--- Сообщение объединено, 5 окт 2018 ---

Вот примеры реализации.

 

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

 

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

 

f13nd, привычка с этим масмом.
К слову, что такое fasm-g? юзали его? Оригинальный фасм будет развиваться параллельно , или как?