Pull to refresh

Comments 24

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

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

если ключ равен длинне сообщения то шифр Вернама

еще Шеннон доказал что он не взамываем

при условии что ключ случан

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

Бессмысленно, см "шифр Вернама", если размер ключа равен размеру текста, но идея интересная.

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

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

Передача ключей это совсем другая тема

Так Вы ни в теме шифрования, ни в теме ключей не разбираетесь.

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

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

Я разбираюсь, обмен ключей идёт через разные каналы связи, или через один, но зашифрованный, или сам ключ должен быть зашифрованный, как это делается в паре AES/DES, так же я написал что можно передавать хеши как открытый шифротекст, а сгенерированный байты как закрытый, можно и так и так

Не понял примерно ничего. Вот тот самый список хешей (который Вы назвали секретным ключом), который размером с 32 х количество_символов_сообщения надо передавать, чтобы расшифровать шифртекст? Тогда у схемы относительно XOR только недостатки.

Ничего не понял. А если привлечь Алису и Боба? У Алисы есть открытый текст Secret data, Алиса "придумывает" шифртекст Yuh6Gfhh8jC. Далее Алиса используя открытый текст и шифртекст формирует секретный ключ их хэшей. И передает шифртекст Бобу. Вопрос - где Боб возьмет секретный ключ? Ведь заранее его передать нельзя. Он хронологически появляется после шифртекста.

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

В конце указал на это

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

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

Ну и про длину ключа уже написали выше.

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

Плюсы в оценках комментариев про бессмысленность предложенного метода)

магистерской дипломной работы на тему шифрования и расшифровки данных с помощью хеш-функции xxHash

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

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

В каком, говорите, вузе защищались? Магистерская, говорите, степень?

Для магистерской работы как-то слабовато. Думаю, если бы Ривест с Шамиром так описали бы свой алгоритм - их бы до защиты не допустили

Можно сделай ключ статичный и передавать хеши

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

В конце указал на это

Что действительно важно — так это то, что поиск хешей, как минимум теоретически, можно перенести на GPU.

Это как раз не важно. Но хуже всего то, что вы даже не понимаете проблемы... :(

доработать алгоритм так, чтобы открытым ключом были хеши

... и взламывать его можно будет даже не на gpu, а на калькуляторе.

Можно ваш калькулятор который может перебрать 256^n, где n длина сообщения?

Видим, что на первом месте стоит 8, а нам нужно, чтобы было 5 (первый символ из 5365637265742064617461), поэтому продолжаем дальше генерировать байты и искать нужный хеш — по моим наблюдениям, в среднем для этого нужно около 10 попыток

По ощущениям... Около 10 повторов...Господи, да тут ещё и хэш дерьмовый. Если у вас "около 10 попыток", то ваш хеш на раз ломается (можно найти функцию подбора исходного сообщения по хэшу). И если вы не можете ответить на вопрос "почему", то двойка вам вне зависимости от содержания остального текста (которых тоже бредовый)

Sign up to leave a comment.

Articles