Софт Исходник Hexagon Cryptor (file encryptor\decryptor)

Monolith Development
Участник
Статус
Оффлайн
Регистрация
8 Мар 2018
Сообщения
568
Реакции[?]
198
Поинты[?]
34K
1700871543509.png
Ключ должен быть ровно 32 символа длиной
IV должен быть ровно 16 символов длиной
Иначе программа напишет что не верный Key или IV в зависимости что вы указывали

Плюсы:
  1. Работает на Windows, Linux
  2. Открытый исходный код
  3. Возвращает исходный формат файла после расшифровки
  4. Имеет небольшое сжатие файла который шифруется, и исходного файла

Windows x86-x64
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.
Linux x86-x64
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.
 
Последнее редактирование:
how to get json?
Пользователь
Статус
Оффлайн
Регистрация
10 Окт 2019
Сообщения
314
Реакции[?]
54
Поинты[?]
16K
Посмотреть вложение 264508
Ключ должен быть ровно 32 символа длиной
IV должен быть ровно 16 символов длиной
Иначе программа напишет что не верный Key или IV в зависимости что вы указывали

Для чего может быть полезен:
  1. Хранение личных файлов на не анонимных хостингах или в других иных местах
  2. Продажа любого файлового контента с хранением файлов в телеграмме и передаче ключей от файла после покупки
  3. Т.д.

Плюсы:
  1. Работает на Windows, Linux
  2. Открытый исходный код
  3. Возвращает исходный формат файла после расшифровки
  4. Имеет небольшое сжатие файла который шифруется, и исходного файла

Windows x86-x64
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.
Linux x86-x64
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.
ооо наш, на расте пишет!!!
 
Monolith Development
Участник
Статус
Оффлайн
Регистрация
8 Мар 2018
Сообщения
568
Реакции[?]
198
Поинты[?]
34K
Обновил до 1.0.1
Добавлен показ сколько символов нужно ввести для ключа и Iv
Исправлен краш если у файла нету расширения1702380323945.png
 
Последнее редактирование:
Начинающий
Статус
Оффлайн
Регистрация
12 Май 2023
Сообщения
29
Реакции[?]
27
Поинты[?]
25K
Посмотреть вложение 264508
Ключ должен быть ровно 32 символа длиной
IV должен быть ровно 16 символов длиной
Иначе программа напишет что не верный Key или IV в зависимости что вы указывали

Плюсы:
  1. Работает на Windows, Linux
  2. Открытый исходный код
  3. Возвращает исходный формат файла после расшифровки
  4. Имеет небольшое сжатие файла который шифруется, и исходного файла

Windows x86-x64
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.
Linux x86-x64
Пожалуйста, авторизуйтесь для просмотра ссылки.
Пожалуйста, авторизуйтесь для просмотра ссылки.

Пожалуйста, авторизуйтесь для просмотра ссылки.
Чем это лучше gpg/pgp?
 
Keine panik!
Эксперт
Статус
Оффлайн
Регистрация
29 Апр 2020
Сообщения
812
Реакции[?]
417
Поинты[?]
49K
Немножко критики
1.
Ключ должен быть ровно 32 символа длиной
IV должен быть ровно 16 символов длиной
Иначе программа напишет что не верный Key или IV в зависимости что вы указывали
Это очень плохой вариант на самом деле, юзер привык указывать онли пароль, в архиваторах обычно используется алго по расширению пароля до нужного размера ключа
Так же юзер не хочет указывать два пароля, один для ключа, другой для вектора инициализации
2. Насколько я понимаю внутри алго нет никакой проверки целостности
Стоит добавить криптографический хэш и сравнивать расшифрованный файл, чтобы точно убедиться что никаких проблем не произошло
3. В шифрованном файле нет никакой метаинфы, ни версии, ни используемых алгоритмов, у тебя просто нет пространства для выпуска новых версий без ломания совместимости, а ведь кто-то уже мог защитить твоей старой версией (к примеру)
4. Не шарю за раст, возможно там такой стиль кода это норм
1703678693064.pngНо это страшно видеть
5. Вот этот момент странный
1703678757332.png
Сжимать зашифрованные данные контрпродуктивно
Сжатие строится на элиминации одинаковых последовательностей, после шифрования у буффера будет высокая энтропия и сжатие не даст ровным счетом ничего
 
Monolith Development
Участник
Статус
Оффлайн
Регистрация
8 Мар 2018
Сообщения
568
Реакции[?]
198
Поинты[?]
34K
Немножко критики
1.

Это очень плохой вариант на самом деле, юзер привык указывать онли пароль, в архиваторах обычно используется алго по расширению пароля до нужного размера ключа
Так же юзер не хочет указывать два пароля, один для ключа, другой для вектора инициализации
2. Насколько я понимаю внутри алго нет никакой проверки целостности
Стоит добавить криптографический хэш и сравнивать расшифрованный файл, чтобы точно убедиться что никаких проблем не произошло
3. В шифрованном файле нет никакой метаинфы, ни версии, ни используемых алгоритмов, у тебя просто нет пространства для выпуска новых версий без ломания совместимости, а ведь кто-то уже мог защитить твоей старой версией (к примеру)
4. Не шарю за раст, возможно там такой стиль кода это норм
Посмотреть вложение 267126Но это страшно видеть
5. Вот этот момент странный
Посмотреть вложение 267127
Сжимать зашифрованные данные контрпродуктивно
Сжатие строится на элиминации одинаковых последовательностей, после шифрования у буффера будет высокая энтропия и сжатие не даст ровным счетом ничего
Ну на счет третьего варианта у меня своя идеалогий что человек если сделает перебор паролей он не узнает что должно получится в исходном варианте
 
Сверху Снизу