Comments 14
Шифрование одних и тех же сообщений одним и тем же конечным шифром — если не прямая уязвимость, то явный шаг в ее сторону.Это уязвимость не шифрования, а протокола обмена сообщениями. Самый простой способ — это поставить счетчик сообщений: если сообщения приходят повторно с одинаковым счетчиком — отбрасываем, если сообщения приходят с меньшим счетчиком или гораздо бОльшим — отбрасываем.
Посмотрел исходники, скармливание sha512 в md5, посмеялся. Прочитал "криптографически стойкий алгоритм шифрования", потом глянул на функцию cipher и посмеялся еще раз. Спасибо, то что нужно для пятницы!
Предвосхищая комментарии про особые органы и аспекты взаимоотношения с ними, в случае, если деятельность имеет отношение к криптографии, забегая вперед, скажу, что работа ведется исключительно в экспериментальных и исследовательских (некоммерческих) целях.А можно комментарий для тех, кто не в теме? С какими органами и о чём надо взаимоотношаться в случае, если деятельность имеет отношение к криптографии если работа ведётся в коммерческих целях?
Основная идея прелесть получившегося алгоритма заключается в том, что для каждого акта шифрования не используется один и тот же секретный ключ, а генерируется функция обхода исходного ключа, так называемая сигнатура пути обхода (pathKeySignature в коде)
Реальные потоковые шифры кроме ключа используют еще вектор инициализации. Таким образом каждый раз получается уникальная гамма. Вы фактичести изобретаете велосипед.
в алгоритм внесены элементы двухфакторного шифрования (более подходящего термина не нашел, речь идет о коротких пин-паролях у отправителя и получателя, подробнее ниже по тексту)
Потоковые шифры часто используются как строительные элементы многих криптографических протоколов, но на этом их применение не заканчивается. Что делать в ситуации, когда нет получателя?) Ну и использование коротких пин-паролей тоже сомнительная идея т.к. их можно быстро брутфорсом перебрать. Шифрование часто происходит без взаимодействия с пользователем, что делает идею использования пин-паролей еще более сомнительной.
метод byteShifting дополнительно вносит хаотичность в генерируемый шифр посредством добавления различных сдвигов в определенных границах.Вы не описали подробности реализации метода byteShifting. Из каких соображений он проектировался? Что значит «вносит хаотичность» в терминах безопасности? А ведь это очень важно!
2 мегабайта рандомного текста было зашифровано и расшифровано за 4 секундыЯ подозреваю что вы как-то неправильно тестировали шифр. Слишком медленно. Тем более на i7-8700. Собственно, основным преимуществом поточных шифров является их скорость.Пример из недавнего — в Украине в конце 2019 года приняли новый стандарт поточного шифрования — «Струмок». Его скорость 18 Гб/c)
Это очень класно, когда люди пытаются создать что-то свое. Но боюсь, вам не хватает знаний для разработки своего шифра. Я бы рекомендовал вам разбраться в конструкциях существующих шифров и почему они являются криптостойкими, прежде чем приступать к разработке собственной.
Потоковые шифры часто используются как строительные элементы многих криптографических протоколов, но на этом их применение не заканчивается. Что делать в ситуации, когда нет получателя?) Ну и использование коротких пин-паролей тоже сомнительная идея т.к. их можно быстро брутфорсом перебрать. Шифрование часто происходит без взаимодействия с пользователем, что делает идею использования пин-паролей еще более сомнительной.
Не знаю насколько внимательно вы вчитались в алгоритм. Речь идет не о тех пин-паролях, которые отправляются в смс пользователям или посредством push сообщений приходят, разумеется, это просто некие инициализационные параметры, с которыми вызываются классы для шифрования/дешифрования на первой и второй стороне. Они постоянные. Перебрать их брутфорсом не получится, просто потому, что они нигде напрямую не вызываются, используются только хеши от них и соли приложения.
Я подозреваю что вы как-то неправильно тестировали шифр. Слишком медленно. Тем более на i7-8700. Собственно, основным преимуществом поточных шифров является их скорость.Пример из недавнего — в Украине в конце 2019 года приняли новый стандарт поточного шифрования — «Струмок». Его скорость 18 Гб/c)
Подозреваю, там идет речь о компилированном оптимизированном коде. Когда же речь идет о языке программирования, применяемом в вебе, никакие веб-процессы (неважно, шифрование это или банальный trim() переданной строки) не способны развивать скорость в 18Гб/с.
Вы не описали подробности реализации метода byteShifting. Из каких соображений он проектировался? Что значит «вносит хаотичность» в терминах безопасности?Там реализуется возможность захвата как можно большего количества utf-8 символов кодирования и проверка, что мы находимся в разрешенном диапазоне символов. Это требуется для того, чтобы затруднить понимание из какого набора символов бралось исходное сообщение. Без этого метода результирующий шифр будет отличаться, например, для текста на кириллице и для иероглифов примерно из середины таблицы Unicode.
Таким образом каждый раз получается уникальная гамма. Вы фактически изобретаете велосипед.
Может быть, но скорее не велосипед, а один из методов, имеющий право на существование наравне с другими. Далеко не лучший, возможно, с точки зрения промышленной криптографии, но свой.
Криптография очень сложна. Она сложна даже для экспертов в области криптографии. Потому одно из главных правил — не пиши свои шифры, если ты не эксперт, пользуйся готовым и проверенным. Так что это очень странное тестовое задание.
uniqid
Эта функция возвращает НЕуникальное значение. Это всего лишь форматирование текущего времени, в ней нет никакой рандомизации. Даже на странице в документации это сказано и написано, что её нельзя использовать в криптографических целях.
в качестве задания стояла задача разработать нестандартный алгоритм симметричного шифрования на высокоуровневом яп, идейно в чем-то непохожий на классику жанра — операцию xor исходного сообщения и секретного ключа
Но ведь весь ваш алгоритм свёлся к обычному XOR, приправленному модификацией ключа.
Лучше используйте для этих целей AES256, если вам нужно надежно, и RC4, если вам нужно быстро. Используйте HMAC-SHA3, если вам нужна симметричная подпись, или ECDSA, если нужна асимметричная. Используйте ECDH, если вам нужно согласовать симметричный ключ.
То, что вы сделали, просто ужасно — накинуть друг на друга кучку хэшфункций и добавить перестановку на основе значения хэша не делает ваше "шифрование" сколько бы то ни было безопасным, оно даже не делает его шифрованием. Все, что вы сделали, по сути, это слабую KDF-функцию, которую в псевдокоде, продравшись через php, можно представить следующим образом:
def get_pks_sha256(user1_md5, user2_md5, plaintext, salt):
t = time_ns()
sec = t // 1000000000
usec = ((t % 1000000000) % 0x100000) % 0xF4240
uniqid = sprintf('%08x%05x', sec, usec)
attach_md5 = md5_hex(
sha512_hex(utf8_encode(plaintext + uniqid + salt))
+ sha512_hex(utf8_encode(salt))
)
return sha512_hex(user1_md5 + attach_md5 + user2_md5)
def kdf(pks_sha512, key):
ki = 0
pos = 0
for i in [0..]:
ki = (ki + hex2dec(pks_sha512[i % 32])) % len(key)
d = (i % 2) ? -1 : 1
pos = (abs(300 * ord(key[ki]) + i * d)) % 2000
if pos <= 65:
pos = 65 * max(pos, 1) + 1
if pos >= 2000:
pos = 200
yield posВсе ваше шифрование заключается в том, что вы xor-ите кодепоинты вашего plaintext с бесконечным выхлопом этой kdf. Не надо так.
Плюс в вашей реализации еще и есть баги, которые вы не заметили — например, salt в конструкторе всегда перезаписывается независимо от его длины. Вы используете хэш в 32 байта, но ходите только по 32 байтам его шестнадцатеричного представления, которое имеет длину в 64 байта, и т.д.
И помните — очень легко сделать алгоритм, который вы сами не сможете взломать. Куда сложнее сделать такой, который не смогут взломать остальные. Потратьте время на обучение криптоанализу, разберитесь с криптографическими примитивами и почему они такие, разберитесь с векторами атак, в том числе по сторонним каналам, и только после этого вы сможете, возможно, обсуждать идеи обоснованно безопасных криптографических алгоритмов, а не просто сваливать все в кучу.
Разработка собственного алгоритма симметричного шифрования на Php