Потоковые шифры часто используются как строительные элементы многих криптографических протоколов, но на этом их применение не заканчивается. Что делать в ситуации, когда нет получателя?) Ну и использование коротких пин-паролей тоже сомнительная идея т.к. их можно быстро брутфорсом перебрать. Шифрование часто происходит без взаимодействия с пользователем, что делает идею использования пин-паролей еще более сомнительной.
Не знаю насколько внимательно вы вчитались в алгоритм. Речь идет не о тех пин-паролях, которые отправляются в смс пользователям или посредством push сообщений приходят, разумеется, это просто некие инициализационные параметры, с которыми вызываются классы для шифрования/дешифрования на первой и второй стороне. Они постоянные. Перебрать их брутфорсом не получится, просто потому, что они нигде напрямую не вызываются, используются только хеши от них и соли приложения.
Я подозреваю что вы как-то неправильно тестировали шифр. Слишком медленно. Тем более на i7-8700. Собственно, основным преимуществом поточных шифров является их скорость.Пример из недавнего — в Украине в конце 2019 года приняли новый стандарт поточного шифрования — «Струмок». Его скорость 18 Гб/c)
Подозреваю, там идет речь о компилированном оптимизированном коде. Когда же речь идет о языке программирования, применяемом в вебе, никакие веб-процессы (неважно, шифрование это или банальный trim() переданной строки) не способны развивать скорость в 18Гб/с.
Вы не описали подробности реализации метода byteShifting. Из каких соображений он проектировался? Что значит «вносит хаотичность» в терминах безопасности?
Там реализуется возможность захвата как можно большего количества utf-8 символов кодирования и проверка, что мы находимся в разрешенном диапазоне символов. Это требуется для того, чтобы затруднить понимание из какого набора символов бралось исходное сообщение. Без этого метода результирующий шифр будет отличаться, например, для текста на кириллице и для иероглифов примерно из середины таблицы Unicode.
Таким образом каждый раз получается уникальная гамма. Вы фактически изобретаете велосипед.
Может быть, но скорее не велосипед, а один из методов, имеющий право на существование наравне с другими. Далеко не лучший, возможно, с точки зрения промышленной криптографии, но свой.
А ведь не за горами и дипфейки по видеозвонкам и видеосообщениям.
Не знаю насколько внимательно вы вчитались в алгоритм. Речь идет не о тех пин-паролях, которые отправляются в смс пользователям или посредством push сообщений приходят, разумеется, это просто некие инициализационные параметры, с которыми вызываются классы для шифрования/дешифрования на первой и второй стороне. Они постоянные. Перебрать их брутфорсом не получится, просто потому, что они нигде напрямую не вызываются, используются только хеши от них и соли приложения.
Подозреваю, там идет речь о компилированном оптимизированном коде. Когда же речь идет о языке программирования, применяемом в вебе, никакие веб-процессы (неважно, шифрование это или банальный trim() переданной строки) не способны развивать скорость в 18Гб/с.
Там реализуется возможность захвата как можно большего количества utf-8 символов кодирования и проверка, что мы находимся в разрешенном диапазоне символов. Это требуется для того, чтобы затруднить понимание из какого набора символов бралось исходное сообщение. Без этого метода результирующий шифр будет отличаться, например, для текста на кириллице и для иероглифов примерно из середины таблицы Unicode.
Может быть, но скорее не велосипед, а один из методов, имеющий право на существование наравне с другими. Далеко не лучший, возможно, с точки зрения промышленной криптографии, но свой.