Релиз моего шифратора Cryptos 2.3

Событие настолько радостное, что без юмора никак!


После тяжёлых и продолжительных мучений мне удалось довести до готового к рабочему применению состояния вторую версию шифратора Cryptos. Умри Павел Дуров от зависти! Теперь в любая личная переписка любых двух козлов будет нечитабельна для всех остальных, пока один из этих двух козлов не потеряет ключ.


Релиз на SourceForge: https://sourceforge.net/projects/cryptos-encoder/


Релиз на GitHub: https://github.com/alexwolf1975/CryptosEncoder


Убейтесь головой об стену ФСБ, ЦРУ, Моссад, СБУ и Ми-6! Вы теперь мои шифровки будете до нового Большого Взрыва расшифровывать! Бизнесмены, сценаристы, писатели, ценных идей изобретатели, программисты, кодеры и прочие теперь могут быть уверены, что их информацию никто не расшифрует без их личного ключа.


Принцип работы: многоступенчатое шифрование. Сначала весь объём информации перемешивается по ключу и трём хэширующим последовательность значениям. Потом накладывается битовый шум на всю длину по ключу и с хэширующей длину сообщения функцией. Потом вся последовательность умножается на хэшированное от его длины значение ключа длинной арифметикой, при этом один из множителей является очень большим простым числом. Потом снова накладывается битовый шум, аналогично первому и снова происходит перемешивание, аналогичное первому. А теперь не имея ключа попробуйте расшифровать!


Рассмотрим работу на конкретном примере. Возьмём любой файл с любым содержанием. Чтобы понять было проще, возьмём просто небольшой текст.


Этот файл содержит ужасные оскорбления всех, за которые автора обязательно посадят!

А здесь вообще государственная тайна! Тут — военная! Здесь — номера банковских счетов,

может быть, в швейцарском банке. А это компромат на всё правительство.


Чтобы никто и никогда, кроме владельцев ключа, не расшифровал это послание, мы его зашифруем. Для этого можно воспользоваться генератором SHA и создать ключ из произвольной строки, а можно поступить гораздо интереснее и создать ключ самим шифратором из ваших любимых фраз. Напишем эти фразы и сохраним в Послание.txt.


Сотрудник мой — КОЗЁЛ!!! Ребёнок мой — урод! Жена моя — паскуда и тёща моя — тварь!


Нормальный человек до таких гадостей точно не додумается, поэтому повторить высказывание будет некому. Зашифруем это ключевое послание хоть номером вашего телефона 322323223322, который мы точно помним и поместим в файл Шифр.txt.


>: python3 cryptos2.3.py -e -mpn -c Шифр.txt -b16 -i Послание.txt -o Послание.txt.crp


Открываем файл Послание.txt.crp и превращаем его в шифр просто заменив первые два символа в строке на 0X. Можно и просто приписать спереди 0X, на ваше усмотрение. Получается вот такой ключ в файле Шифр.txt.


0XDB7F2A070217C7318226A88B07822C9056B400DA29A168FC930DCA792F1704

3C33B5B7CE39F06FD9CB7E791725815564C6A2EB04E0D3CAAEFE0143A9FD585C

4C7C4CF927FD60939007BBD196A11AE07CCBDE069AAAF6A6AED503828F9D537E

0CD531FBACA73FE1564DA194D73E827E4ABD5C850A4B88D0BD7999C6D224AC9B

ED3F66D8883B908CE82A94D1F06778DC2F3DC1A3FA520ECA5E609AD4


А теперь кладём в Послание.txt всё, что нам нужно зашифровать и шифруем! Чем длиннее ключ, тем дольше происходит шифрование при ключе запуска -mpn.


>: python3 cryptos2.3.py -e -mpn -c Шифр.txt -b64 -i Послание.txt -o Послание.txt.crp


В итоге получаем файл Послание.txt.crp следующего содержания.


-b64

dUh0aRDpNDQzwfkdMvf8bWkEngvuQAUQmsb2Vw3vaDo5tLANMxYxRgUdQYdRDRrL

jvpjy56zbCd6jc+1tE0ErHfoPqfZUHNh2yEfu18yfGqcFwcFAE6Rhyha8XFoGxiR

tu40tIuysXT2wRisBP6HzTYsPvSE0LiS2XVhqyfG99NdmxONbo8Y7xlr0ytJEC+L

sMVG8MGtKk0V9TX9lGIRHbHwKrTpLBPysGE1eswfYB1O5DKcfqnlonCVYNqi0DeB

IBORlwg3HATgLTefc9xg5OiVJHGVTzcbcbcKUP+QlgLseX3t4xvKr9VMKgV+c6r+

lI+D8UFG3wvg2A22yfv7sAFr6O12MXPm6A6VROGA7KW1FvxFKFG/FulS8SarEkmg

f/PTV1/oKm2ibzkIMifjsblLXMl3pzfXcmor5/XfcrNPDhYi8BZ3W42C1byOfoDH

0i0HOmOk2aBpDKGQBrYpRhnkuty8Z10yBg65cxwvKpdPRnvqN3f7qJfb3TRQHqRb

PSV/q7LvG1oa0WKLdIJ8qSmjKBXh/RTSnGcKv1MVJ9V47lE1NczY1anpN+e9gwqj

zkcZBVs9Ha/shrCcAK6tKpj9CgZjwLBi9Kf+q5pX+p0oK3sCCyi0C8iOUM55lLnx

YiMJliflcmt4F281HV1tkbtGSNUe+X+EvdPg7Vmhy4t0E6b4q2q3NQu0UcP22mly

5hWEomaE6M8TKCHdX7BlqomLLg7WbxBfqIdm5NDFSiUPHivOAtmHNHuIZk5e216W

eclscf4NixvZzQ+SphZjqVWGmDJoVUg=


Можете хоть посылать почтой, хоть выкладывать на сайт в открытый доступ. Расшифровать это без ключа не получится! Только надо не перепутать кодировки windows-1251 или UTF-8 в редакторе и ключи -b16 или -b64, если захочется восстановить ключ по памяти. А когда понадобится расшифровать файл Послание.txt.crp выполняем обратное действие с выводом в Послание.txt.dcd.


>: python3 cryptos2.3.py -d -mpn -c Шифр.txt -b64 -i Послание.txt.crp -o Послание.txt.dcd


Открывая файл Послание.txt.dcd находим в нём сакраментальную фразу.


Этот файл содержит ужасные оскорбления всех, за которые автора обязательно посадят!

А здесь вообще государственная тайна! Тут — военная! Здесь — номера банковских счетов,

может быть, в швейцарском банке. А это компромат на всё правительство.


Но это ещё не всё! Ключом -mpn удобно шифровать маленькие файлы, которые по длине сравнимы с длиной шифра потому, что в алгоритме при этом используется умножение на очень большое простое число. Если надо зашифровать файл в десятки раз превышающий длину ключа, то можно сделать это ещё надёжнее с ключом -cns, который шифрует уже делением на очень большое, получаемое из шифра число, переводя содержимое файла в число с неизвестным никому огромным основанием системы счисления.


>: python3 cryptos2.3.py -e -cns -c Шифр.txt -b64 -i Послание.txt -o Послание.txt.crp


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


>: python3 cryptos2.3.py [-h] [-v] (-e | -d) (-mpn | -cns) -c cipher_file (-b16 | -b64) -i input_file -o output_file


-h, --help: показать помощь по использованию.

-v, --verification: выводить больше информации.

-e, --encryption: шифрование.

-d, --decryption: расшифровка.

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

-cns, --ciphersystem: шифрование переводом в систему счисления с большим основанием на основе шифровального ключа. Рекомендуется для использования с большими объёмами информации, многократно превышающими длину ключа.

-c file, --cipher file: файл с ключом шифра.

-b16, --io_base16: чтение и запись в формате base16. Рекомендуется для генерации больших ключей.

-b64, --io_base64: чтение и запись в формате base64.

-i file, --input file: шифруемый входной файл.

-o file, --output file: зашифрованный выходной файл.


Да пребудет с вами Хаос тайна!

Вы смотрите срез комментариев. Показать все
39
Автор поста оценил этот комментарий

Пробуем:

echo "Этот файл содержит ужасные оскорбления всех, за которые автора обязательно посадят!

А здесь вообще государственная тайна! Тут — военная! Здесь — номера банковских счетов,

может быть, в швейцарском банке. А это компромат на всё правительство." > Послание.txt

echo "1234567890" > Шифр.txt

python3 cryptos2.3.py -e -mpn -c Шифр.txt -b16 -i Послание.txt -o Послание.txt.crp

Проблема 1: 

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


Но мы же настоящие исследователи? Давайте проверим хотя бы качество шифра по энтропии шифротекста - просто пожмём его скажем с помощью 7z:

Послание.txt.crp 924 байта

Послание.txt.crp.7z 750 байт

Да у него энтропия никакая! 924 байта ужались. Они реально стали меньше под арихватором!

Ладно - возможно это проблема связана с выходным форматом, хранящим результат в 16ричном виде.


Провернём следующий трюк - сожмём исходный текст с помощью 7z:

Послание.txt 445 байт

Послание.txt.7z 405 байт

Похоже наше предположение верно - шифротекст сжался сильнее чем исходный текст. Шифруем:


python3 cryptos2.3.py -e -mpn -c Шифр.txt -b16 -i Послание.txt.7z -o Послание.txt.7z.crp

Послание.txt.7z.crp 842 байт

Послание.txt.7z.crp.7z 697 байт

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

Это дорогой вектор атаки, но он есть - можно попробовать анализировать алгоритм.

Просто по инерции попробуем что там с двукратным шифрованием:

python3 cryptos2.3.py -e -mpn -c Шифр.txt -b16 -i Послание.txt -o Послание2.txt.crp

> cat Послание.txt.crp

-pnm -b16

5E16DA469EF7B28FBFA4D07A212E698AAD6D8144421D73F1D9C1792B3BC415F8

DB615D1A6D267B8E5BCE40D6CE1746A9A36492DE846DAF821C6C89761A61646D

6F2C5CAB0DAD62A90346CECF3B2C2EA96419E055764E6099810EA48173BC6146

9FDCBB7823AE3AB4CF178A4A2987559F927F7112C4A1041935BF2B103BC08852

273365441C9F14C69E009CAA5AF41CFA512FC7D6789939E1A925A9363DF95A75

11260A3604F27EBE51E3C536916D6ED3E223EBE3A4DA7260F433874F6393E7F5

1360784E23EF3F2B9CB2A74871DAC35A3FE4B9BBB24911532AF9F9FC65D141FF

791A0FE69A97222EBA9C9581D8E815AA908BD25E9D19455AF1930B16E845F5B9

1368FBED448525DF595DB983CA46F152005F99A681F9E28651E622F2CDED0360

BD783655E4683AEB11EAC320E9A563C263410E3D53C465542B7B9713982AFDBA

A5905FB6581BBC6353133912947E2556AEF422CACA3F069E6BA3C2EFB8023533

51F7ACDEC071AC8A4ADF1421DD0CBEB7F405B52F75042C057268424AC32814CE

791D0740E5854C7AE670CFB60D98DA1D986615FE5F4351331D1FA69B8A568DCD

B8EFAA81C57A3A6174E6BDD529F577EF13FAD62A6C8867E5CACD7FCB3AA123A9

538E⏎

> cat Послание2.txt.crp

-pnm -b16

5E16DA469EF7B28FBFA4D07A212E698AAD6D8144421D73F1D9C1792B3BC415F8

DB615D1A6D267B8E5BCE40D6CE1746A9A36492DE846DAF821C6C89761A61646D

6F2C5CAB0DAD62A90346CECF3B2C2EA96419E055764E6099810EA48173BC6146

9FDCBB7823AE3AB4CF178A4A2987559F927F7112C4A1041935BF2B103BC08852

273365441C9F14C69E009CAA5AF41CFA512FC7D6789939E1A925A9363DF95A75

11260A3604F27EBE51E3C536916D6ED3E223EBE3A4DA7260F433874F6393E7F5

1360784E23EF3F2B9CB2A74871DAC35A3FE4B9BBB24911532AF9F9FC65D141FF

791A0FE69A97222EBA9C9581D8E815AA908BD25E9D19455AF1930B16E845F5B9

1368FBED448525DF595DB983CA46F152005F99A681F9E28651E622F2CDED0360

BD783655E4683AEB11EAC320E9A563C263410E3D53C465542B7B9713982AFDBA

A5905FB6581BBC6353133912947E2556AEF422CACA3F069E6BA3C2EFB8023533

51F7ACDEC071AC8A4ADF1421DD0CBEB7F405B52F75042C057268424AC32814CE

791D0740E5854C7AE670CFB60D98DA1D986615FE5F4351331D1FA69B8A568DCD

B8EFAA81C57A3A6174E6BDD529F577EF13FAD62A6C8867E5CACD7FCB3AA123A9

538E⏎

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

Нам даже не нужно буде анализировать алгоритм - мы поломаем его на заголовках файлов :)


Теперь уже точно шифратор отправляется в мусор - пользоваться этим нельзя.

раскрыть ветку (33)
9
Автор поста оценил этот комментарий
Коллега, ну он же старался.
Надо похвалить за попытку и старание.
раскрыть ветку (3)
15
Автор поста оценил этот комментарий

Ок. ТС, получает благодарность за старание и следующие рекомендации:


1 Почитать что-нибудь приличное о симметричном шифровании


2 Понять какие требования предъявляются к современным шифрам (ваш текущий шифр ещё и очень, очень медленный, даже для реализации на python)


3 Изучить как устроены современные шифры. Хорошие классические примеры:
https://ru.wikipedia.org/wiki/Blowfish

https://ru.wikipedia.org/wiki/ГОСТ_28147-89


4 Попробовать написать реализацию одного из них (лучше не ГОСТ - там не ясные проблемы с таблицами подстановки)


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

раскрыть ветку (2)
1
Автор поста оценил этот комментарий
Иллюстрация к комментарию
Автор поста оценил этот комментарий

А я бы еще посмотрел откуда у него генератор шума ;-)

2
Автор поста оценил этот комментарий
Я зашёл ради этого коммента.
Автор поста оценил этот комментарий
В идеале, ключ шифротекста должен быть длиннее послания. "Шифротекст не длиннее исходного текста" - не будет выполняться, если мы о симметричном шифровании говорим (а у автора это оно, если я всё правильно понял). Там блоки данных последовательно xor-ятся, попасть так чтобы точное количество блоков - нереально. Почти всегда будет больше исходного в пределах одного блока.
раскрыть ветку (2)
Автор поста оценил этот комментарий
С хрена ли? Режим гаммирования используйте, и будет вам счастье.
1
Автор поста оценил этот комментарий
мы о симметричном шифровании

Мы о нем, но у автора не блочный шифр.


Там блоки данных последовательно xor-ятся, попасть так чтобы точное количество блоков - нереально. Почти всегда будет больше исходного в пределах одного блока.

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

Хотя если мы подаём на вход уже хорошо сжатые данные - шифротекст будет длинее, это понятно.

При хорошем раскладе мы ещё в начала будем цеплять соль, различной длины (я бы брал длинной от 2 до 3 блоков, но не возьмусь сейчас доказывать почему именно так), так что на выходе будем получать текст ещё и разной длины.

1
Автор поста оценил этот комментарий

TEACH ME!!!

DELETED
Автор поста оценил этот комментарий

Круто!!! Я как бы всё что вы рассказали легко понял. И даже сам попробовал бы архиваторы с той же целью, что и вы. Но выводы делать не умею, не математик нихуя :(

Поэтому вопрос: а что вы думаете насчёт XOR с достаточно длинной псевдо случайной последовательностью? Это тоже ломается? (понятно, что пустые файлы ксорить нельзя)

...Например у меня есть параноидальная мечта раскодировать microde update Intel, естественно со старых процессоров, в надежде, что там не настоящее шифрование, а тот же XOR. Как думаете есть шанс? (в новых процессорах 100% настоящее шифрование - люди разбирались, там даже в заголовках какие-то стандартные константы для шифрования, т.е. и алгоритм известен. ...А вот старые очень интересно (начиная с +- ~Pentium II и заканчивая Pentium 4)

раскрыть ветку (14)
2
Автор поста оценил этот комментарий
Поэтому вопрос: а что вы думаете насчёт XOR с достаточно длинной псевдо случайной последовательностью? Это тоже ломается?

А чо тут думать? По большому счёту есть только один абсолютно надёжный симметричный шифр - Бесконечный блокнот, где длина ключа == длине исходного текста, а потом выполнен либо XOR, либо деление по модулю.

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

там не настоящее шифрование, а тот же XOR

См. предъидущий абзац - любое настоящие шифрование, это суррогат того самого XOR и попытка обойти его проблему - длинные ключи и/или невозможность получить хорошие исходные данные для ключа. Если у вас есть возможность передавать длинные ключи и генерировать их из хорошего исходника (скажем это квантовый ГСЧ) - не надо ни с чем замарачиваться - используйте их.

т.е. и алгоритм известен

У хорошего шифрования всегда известен алгоритм. Первые шифраторы в очереди отправки на свалку, это те, где не известен алгоритм или способ генерации ключа.

Например самая главная претензия к ГОСТ 28147-89:

Мы не знаем на каком основании и какими методами выбираются таблицы для S блоков. Мы не понимаем, почему таблицы подстановки для ответственного шифрования, которое используют наши спецслужбы, засекречены. Если бы не это проблема алгоритм мог бы получить гораздо большее распространение и более высокий уровень доверия.

1
Автор поста оценил этот комментарий

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

раскрыть ветку (12)
Автор поста оценил этот комментарий

Если генератор заваливается на первой сотне на повтор, то это вообще не генератор.

Починил. Не благодари.


Если будет легко воспроизвести последовательность это не менее плохо.

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

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

раскрыть ветку (10)
DELETED
Автор поста оценил этот комментарий

>  Всяко не хуже, чем просто зашифровать этим же самым алгоритмом


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

раскрыть ветку (4)
2
Автор поста оценил этот комментарий

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

Автор поста оценил этот комментарий

Еще 15 лет назад модно было студентам темы давать типа "прячем сообщение в jpg картинке". До сих пор страдают этим?

раскрыть ветку (2)
Автор поста оценил этот комментарий
Вышло на новый уровень. Нецросети для вотермарок, достаточно популярная тема. Я смотрел ещё из интереса как при помощи специальных шумов искажать картинку, чтобы нейросеть сломалась, а человек все понимал.
DELETED
Автор поста оценил этот комментарий

Не знаю. Я уже 20 лет, как не студент :)

Автор поста оценил этот комментарий

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

раскрыть ветку (4)
Автор поста оценил этот комментарий

Не. Так мы генерируем ключ для бесконечного блокнота не хуже чем блочный шифра.

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

Сделай следующее - возьми или рандом известной длины (скажем 8 байт) или рандом с маркером конца (скажем n байт среди которых нет 0 и кончающиеся 0) и прикрепи к шифруемому сообщению в начало.

После расшифровки ты просто или отбросишь первые 8 байт, или отбросишь первые n байт до первого нуля и этот самый 0. Можешь использовать оба подхода.

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

раскрыть ветку (3)
Автор поста оценил этот комментарий

У меня так самый первый вариант был сделан. Я брал случайные байты длины как сообщение и приделывал в начало или конец, а потом перемешивал. Но я решил, что получается фигня и эту фичу выпилил :)

раскрыть ветку (2)
Автор поста оценил этот комментарий

А вот зря - многие реализации так и делают. Это простой, дешёвый и надёжный трюк.

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

Придётся вернуть в следующем релизе.

DELETED
Автор поста оценил этот комментарий

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


Накладывать друг на друга два XOR (в похожих местах microcode update) пробовал, но ничего не получилось (случайные данные от любых осмысленых данных, даже очень компактных отличаю на глаз хорошо).

Автор поста оценил этот комментарий
Мы не только получили два одинаковых по длине шифротекста - они вообще идентичны!!!
А так и должно быть! Теоретически можно добавить в шифруемый файл дополнительный шум, который будет выбрасываться, но это уже надо продумывать или для следующей версии с дополнительным шумом или можно просто таймштамп в хвосте приделывать. Попробуйте поменять хотя бы одну букву в шифруемом тексте и вывод полностью поменяется.
раскрыть ветку (8)
2
Автор поста оценил этот комментарий

А так и должно быть!

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

Именно так Тьюринг сломал Энигму.


Попробуйте поменять хотя бы одну букву в шифруемом тексте и вывод полностью поменяется.

Я видел. К рассеиванию вопросов нет, в том числе и от конца к началу, но шифр не блочный, и если бы ещё и этого не было, это вообще бы был не шифр.

раскрыть ветку (6)
1
Автор поста оценил этот комментарий

Про Тьюринга я читал, когда это придумывал. Но я в дискретной математике почти полный дебил и дальше алгоритмов Евклида и малой теоремы Ферма не сильно продвинулся. Но я как-то посчитал, что двойной шум и двойное рассеивание достаточно изуродуют любые повторяющиеся куски.

раскрыть ветку (5)
2
Автор поста оценил этот комментарий

А дальше и не надо. Впрочем можно дойти до расширенного алгоритма и теоремы Эйлера (теорема Ферма всего лишь частный её случай) и там не сложно. Этого достаточно. А касательно симметричных алгоритмов всё просто:

1 На вход подаём упорядоченный текст, скажем из одних 0 или 1 или 01010101 и тому подобные тексты

2 Что-то делаем

3 На выходе должен быть хороший не сжимаемые шум, похожий на случайные данные


Если всё так, то то, что мы делаем в 2 по-видимому что-то хорошее ;)

раскрыть ветку (4)
Автор поста оценил этот комментарий
Короче вас скоро в отдел "к" обоих на работу позовут. Сижу читаю. Нихуя не понимаю) нахуя читаю)
раскрыть ветку (3)
Автор поста оценил этот комментарий

Там вы это отделе К своих таких девать некуда. Это всё не великие тайны. Как я выше уже писал - сделать хороший алгоритм шифрования не сильно сложно - сложно доказать что он хороший. Показать что он устойчив к известным векторам атак.

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

раскрыть ветку (1)
Автор поста оценил этот комментарий

Я уже готовлю релиз 2.4 с переменной длиной и всем прочим в строке и почти несжимаемым (на примерно 5% сжимаемым) выходом. И ключи будет есть напрямую строковые.

Автор поста оценил этот комментарий

Прямо как в «Жалобная книга»: «Кто писал не знаю, а я дурак читаю». А. П. Чехов.

Автор поста оценил этот комментарий

Расчехлил свой 3des ecb на ключе 24 байт. При каждой новой итерации содержимое меняется. Это не очень нормально

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку