42

Релиз моего шифратора 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: зашифрованный выходной файл.


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

Дубликаты не найдены

+36

Пробуем:

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
+8
Коллега, ну он же старался.
Надо похвалить за попытку и старание.
раскрыть ветку 3
+15

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


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


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


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

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


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


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

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

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


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

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

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

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

-1

TEACH ME!!!

-1

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

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

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

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

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

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

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

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

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

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

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

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

-1

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

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

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

0

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

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

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


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

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

раскрыть ветку 6
+2

Круто, что автор интересуется темой. Но как по открытым каналам связи передать ключ другому участнику переписки(например, в другую страну)?

Есть интересная тема - ассиметричное шифрование. Например PGP (или GPG). Вроде с открытым исходным кодом. Человек генерирует открытый и закрытый ключ. Открытый ключ публикует в открытом доступе. Любой может зашифровать сообщение открытым ключем, а расшифровать можно только закрытым ключем.

+2

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

+1

Вах человек изобрел openssl :-)

+1

Написать хороший симметричный шифр не сложно (хотя у вас не получилось: #comment_172014952 ), сложно доказать что он хороший. Как вы собираетесь это делать?

Почему я должен выбрать его, а не десяток других, проверенных временем алгоритмов?

раскрыть ветку 3
0

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

раскрыть ветку 2
+1
Открытый код

Это очень хорошо. Почему не написать реализацию заведомо хорошего алгоритма с тем же открытым кодом?

простой для понимания машинный язык, не требуется компиляция

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

можно поймать в компилированном коде закладку, если не проверить чексумму, что для компиляции малополезно

Я тебе больше скажу - нет никаких гарантий, что нет закладки в КОМПИЛЯТОРЕ, если его код закрытый и компиляция любого алгоритма шифрование будет приводить к получению машинного кода скомпрометированного на этапе этой самой компиляции, из казалось бы вполнего годного, и проверенного исходника.

раскрыть ветку 1
0
Кто нибудь переведите код на java
раскрыть ветку 1
0

Этот не надо, следующий гораздо лучше будет.

0

но зачем? что не так с RSA ?

раскрыть ветку 2
0

Ты хотел сказать AES

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

0
тоже любопытно для чего ещё один вел
0
ФСБ помучается, подумает и придет в гости. И объяснит, что у них получилось расшифровать ваше послание и там ядрёная ЦП.
0

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

0

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

+1

А против терморектального криптоанализа защита есть?

раскрыть ветку 3
+6

Где-то на Пикабу асбестовые трусы попадались.

раскрыть ветку 2
0

титановые надо :D

раскрыть ветку 1
+1

Чувак остынь. 2 копеечные флешки на 64гб с ключом белиберды обеспечат полностью принципиально не расшифровываемое сообщение меж адресатами. Пока не напиздят на 64гб

раскрыть ветку 1
0

Я бы купил десяток. Куда 20 копеек переводить?

0

Параноик детектед )) (сарказм)

0

А чем архиватор с длинным паролем хуже?

раскрыть ветку 6
+1

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

-2

Имеет несколько недостатков: один уровень шифрования, один формат вывода, создать пароль по кодовой фразе не может, нужно использовать стороннее ПО.

-1

Рар вроде скопромеНтирован

раскрыть ветку 3
+1
Нет)
раскрыть ветку 2
-4

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

раскрыть ветку 4
0

Автор тренируется разрабатывать СКЗИ, это не запрещено, а такие знания полезны.

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

-1

Будем ждать звонка из очень компетентных мест.

раскрыть ветку 2
-1

Если конечно вы сами не от туда. Обычно они приезжают.

раскрыть ветку 1
Похожие посты
Похожие посты не найдены. Возможно, вас заинтересуют другие посты по тегам: