Comments 39
" очень большой размер ключей, особенно секретного: он по размеру минимум равен длине шифруемого сообщения " - с таким размером ключа достигается абсолютная стойкость шифрования и без плясок с хэшами ;-) Достаточно применить просто XOR
если ключ равен длинне сообщения то шифр Вернама
еще Шеннон доказал что он не взамываем
Бессмысленно, см "шифр Вернама", если размер ключа равен размеру текста, но идея интересная.
Ничего интересного, идея в корне провальная: помимо того что при шифровании на каждый символ сообщения нужно брутфорсить 8! байт того что тут называется "закрытым ключом", чтобы расшифровать шифротекст нужен и открытый и "закрытый ключ", которые при передаче перехватывают, и вообще без проблем расшифровывают текст.
Точно, необходимость передачи закрытого ключа как-то упустил из виду.
Передача ключей это совсем другая тема
Так Вы ни в теме шифрования, ни в теме ключей не разбираетесь.
Должно быть так: получаем пару открытый-закрытый ключ, передаем открытый ключ, которым можно зашифровать секрет и получить шифротекст, отправить владельцу закрытого ключа шифротекст - он сможет им расшифровать шифротекст, закрытый ключ не передается.
А у Вас - из открытого ключа и секрета получается не понятно что, что Вы называете "закрытый ключ". Отправляете получателю открытый ключ, а потом вдогонку ещё и закрытый, потому что из него секрет достается - в итоге нужно потратить кучу вычислительных ресурсов и передать в восемь раз больше данных, чтобы передать, фактически, незашифрованный текст (ибо если всё что надо передатьперехватят - всё расшифровано).
Я разбираюсь, обмен ключей идёт через разные каналы связи, или через один, но зашифрованный, или сам ключ должен быть зашифрованный, как это делается в паре RSA/AES, так же я написал что можно передавать хеши как открытый шифротекст, а сгенерированный байты как закрытый, можно и так и так
Нет, не разбираетесь: если есть разные каналы, то их могут оба прослушивать, и надежность зависит не от вашего шифрования а от вероятности что не оба канала прослушивают. А если канал зашифрованый - то зачем ещё шифровать? AES - это шифрование с паролем, и там те-же проблемы, и для решения этих проблем придумали инфраструктуру открытых ключей, где можно всё передавать по открытым каналам, и даже если все передачи перехватят - не смогут расшифровать сообщение.
Не понял примерно ничего. Вот тот самый список хешей (который Вы назвали секретным ключом), который размером с 32 х количество_символов_сообщения надо передавать, чтобы расшифровать шифртекст? Тогда у схемы относительно XOR только недостатки.
Ничего не понял. А если привлечь Алису и Боба? У Алисы есть открытый текст Secret data, Алиса "придумывает" шифртекст Yuh6Gfhh8jC. Далее Алиса используя открытый текст и шифртекст формирует секретный ключ их хэшей. И передает шифртекст Бобу. Вопрос - где Боб возьмет секретный ключ? Ведь заранее его передать нельзя. Он хронологически появляется после шифртекста.
Рост количества кибератак и нарушений конфиденциальности данных также подчёркивает необходимость надёжных алгоритмов хеширования и шифрования для защиты информационных систем.
Неверно. Подчёркивает, только если этот рост обусловлен растущим количеством прямых взломов зашифрованной инфы, а не поиском дырок в защите, человеческим фактором и прочее. Иначе получается решение проблемы, высосанной из пальца.
Ну и про длину ключа уже написали выше.
А плюсы-то где? Из минусов, бессмысленная сложность, большой ключ. Напоминает картинку про трамвай из буханки хлеба.
магистерской дипломной работы на тему шифрования и расшифровки данных с помощью хеш-функции xxHash
Неужели никто из дипломной комиссии не задал вопроса - ну, хорошо, мы открыто передали шифротекст, а как теперь скрытно передать последовательность хешей - ключ, длиной больше шифротекста?
Причём, в отличии от простого одноразового блокнота, где можно заранее обменяться ключами при личной встрече, в данном случае ключевая информация появляется только после процедуры шифрования? И если такой канал существует, то почему по нему не передать само сообщение без этой бессмысленной возни?
В каком, говорите, вузе защищались? Магистерская, говорите, степень?
Для магистерской работы как-то слабовато. Думаю, если бы Ривест с Шамиром так описали бы свой алгоритм - их бы до защиты не допустили
Можно сделай ключ статичный и передавать хеши
Если немного доработать алгоритм так, чтобы открытым ключом были хеши, он станет более универсальным — но это не главное. Что действительно важно — так это то, что поиск хешей, как минимум теоретически, можно перенести на GPU.
В конце указал на это
Что действительно важно — так это то, что поиск хешей, как минимум теоретически, можно перенести на GPU.
Это как раз не важно. Но хуже всего то, что вы даже не понимаете проблемы... :(
доработать алгоритм так, чтобы открытым ключом были хеши
... и взламывать его можно будет даже не на gpu, а на калькуляторе.
Можно ваш калькулятор который может перебрать 256^n, где n длина сообщения?
Во-первых, это потому, что у вас данных на выходе стало больше чем на входе. Супер эффективный шифр!
Во-вторых, что мешает зная первые несколько символов расшифровать сообщения, сделать перебор только для них и восстановить ваш "секретный" ключ?
В-третьих, ваш шифр ничего не решает, так вместо исходного текста вам в результате нужно каким-то безопасным образом передать больше/столько же информации, как и изначальный текст. А если вы идете это сделать, то зачем вам шифр?
Хеши без соли считаются на радужных таблицах при помощи тех же видеокарт. А как соль передавать? Как о "методе засолки" договариваться?
Можно. Только сначала вы опубликуете вашу изменённую схему шифрования ( 'чтобы открытым ключом были хеши' ). А потом будем разбираться с калькулятором.
И не 256^n, а, как вам правильно написали ниже - 10 * n
Если бы вы сказали использовать майнер то да, но на GPU сейчас считают всё что угодно от графики до нейросетей и различных симуляций.
Видим, что на первом месте стоит 8, а нам нужно, чтобы было 5 (первый символ из 5365637265742064617461), поэтому продолжаем дальше генерировать байты и искать нужный хеш — по моим наблюдениям, в среднем для этого нужно около 10 попыток
По ощущениям... Около 10 повторов...Господи, да тут ещё и хэш дерьмовый. Если у вас "около 10 попыток", то ваш хеш на раз ломается (можно найти функцию подбора исходного сообщения по хэшу). И если вы не можете ответить на вопрос "почему", то двойка вам вне зависимости от содержания остального текста (которых тоже бредовый)
Я вижу что вы абсолютно ничего не поняли, пожалуйста, ознакомьтесь внимательней с материалом или кодом
Вы даже не понимаете, что именно не так в этой фразе :))) если написанное вами правда, то ваш шифр гарантированно ломается поиском коллизий. Но вы этого не поймёте, так как даже не знаете свойств хэш-функций. Сами свою статью читайте, может поймёте, в чём идиотизм. Вы же там вначале про свойства хэшей разглагольствуете, вот и читайте - вам читать полезно, а не писать.
А пока запомните: если у кого-то "по наблюдениям, в среднем нужно около 10 попыток", то где-то уже танцуют от радости специалисты по криптографии.
Слишком много разного рода случайностей при работе алгоритма, что неприемлемо для шифрования. В статье только и написано "если то", "если это". Если работу рассматривать как практику для себя, чтобы понять как работают такие системы - нормально, но что-то серьёзное из этого вряд-ли получится, а давать майнерам вычислять хеши для шифрования твоего сообщения похоже на что-то из разряда "привет незнакомец, передай этот конверт тому молодому человеку за барной стойкой, старайся не вникать в процесс, а просто сделай это", не думаю что это надежено с точки зрения выполнимости, а вдруг сообщение не дойдёт, а вдруг свет отключат и считай потерял ты свое сообщение в блокчейне, а размножать блоки никто тебе не позволит
Просто как способ занять себя - отлично! В исследовании "отсутствие результата - тоже результат"
Как шифрование ради шифрования - ок, есть некоторый диапазон размеров данных, который можно ускорить, значительно потеряв в энергозатратах. Как часть науки о защите информации - бред, т.к. Ева может не только с линий связи снимать зашифрованный текст, а еще ковыряться в твоем ПК, засылать тебе троянов, оставлять бекдоры в ОС и аппаратуре, разработчиков которой она контролирует. И при всем при этом ты должен обеспечивать секретность закрытого ключа.
Перспективы
Если немного доработать алгоритм так, чтобы открытым ключом были хеши, он станет более универсальным — но это не главное. Что действительно важно — так это то, что поиск хешей, как минимум теоретически, можно перенести на GPU. Как показал майнинг, это может быть очень эффективно. Если кто-то сумеет реализовать это, то скорости шифрования могут многократно возрасти — и, думаю, без проблем обгонят AES и DES.
А зачем мне грузить GPU для отправки сообщения в мессенджере? Причем достаточно бездарно грузить. Когда я могу зашифровать его стойким симметричным ключом, а его - открытой частью 4/8/16/32к ключа на эллиптических кривых моего собеседника. И это быстро работает на CPU
А давайте теперь прикинем, что речь не о том, что мы мелкие какие-то операции будем на GPU загонять (прям сейчас представил лицо какого-нибудь дизайнера/проектировщика, у которого скорость рендера скачет из-за его активности на компе, потому что то и дело что-то шифруется. А лицо инженеров Nvidia представили, где в архитектуру профессиональных видеокарт закладывается высокая, но стабильная загрузка, а не как в игровых, которые стабильно высокую могут не пережить, но нормально справляются с пиковыми нагрузками) а замахнемся на какой-нибудь битлокер, который шифрует весь диск или VeraCrypt. Да фиг с ним с полнодисковым шифрованием. Представь себе efs шифрование на твоём алгоритме. Стандартным aes256 я быстро и надежно зашифрую какой-нибудь устав предприятия на 25 листов. А по твоей логике мне нужно будет сгенерировать еще один такой?
А теперь задумайся над тем, что еще есть куча требований по контролю за закрытым ключом, неизвлекаемости, надежной генерации (да, да шумовые диоды опупеют тебе выдавать последовательность такой длины, а если ты это будешь на видяхе делать, то любой нарушитель с физическим доступом все раскрутит). А неизвлекаемость, кстати, накладывает требования, кто бы мог подумать, к тому, что ключ не покидает контейнер, а, значит, твой бедный аппаратный токен будет шифровать все этом в не GPU. И как ты сделаешь извлекаемость в таком случае - не понятно.
Итак, берём первый символ из нашей строки шифротекста "5" и соединяем со случайно сгенерированными 8 байтами в hex-формате (пусть это будет следующая строка c135dc43589da553) — получается 5c135dc43589da553. Хешируем алгоритмом, выбранным ранее (xxHash), и получаем следующий хеш этой строки: 87a0552aa9ee4789.
>>> import xxhash # pip install xxhash
>>> xxhash.xxh64("5c135dc43589da553").hexdigest()
'84793ec10b2d6b2f'
>>>
Не подскажите, почему хеши не сходятся?
Шифрование на основе хешей