Вопрос юным Штирлицам, криптография, man encrypt(3)
"+1" очень похоже на то с чем работает дифференциальный криптоанализ.
в crypt вроде как древний des, а в нём много чего этим методом накопали.
в crypt вроде как древний des, а в нём много чего этим методом накопали.
Вроде да, encrypt похож на обычный DES, по крайней мере по коду не похоже ни на 3DES, ни на 2DES
А заранее известно, что там +1? 
Да, там так. В общем, крипт отменяется
да ладно, можно просто в шифруемый блок добавить случайных данных и само число как-нить размазать поразмашистее.
любой блочный шифр будет не особо стойким если пространство сообщений мало.
любой блочный шифр будет не особо стойким если пространство сообщений мало.
если алгоритм "размазывания" известен, то ситуация от этого не изменится. а стойкость не должна зависеть от секретности алгоритма
2DES - ололо
если у тебя при +1 меняется не два бита в среднем, а половина, причём часть случайно то это основательно затруднит взлом.
а как же традиционный подход solted алгоритмов? Ведь там именно этим и занимаются.
если алгоритм "размазывания" известен, то ситуация от этого не изменится. а стойкость не должна зависеть от секретности алгоритмаДа, это глубочайшая ошибка делать ставку на такую фигню как «но ведь никто не знает, что мы делаем XOR по слову ЧЛЕН, потом разбавляем побитово со случайным набором и делаем BASE64». Такие шифровки делают школьники старших классов.
если у тебя при +1 меняется не два бита в среднем, а половина, причём часть случайно то это основательно затруднит взлом.Все рандомчики завязаны на компутерное время, ну ещё на что-то, что все спецы по секурити разруливают на раз.
hrng никто не отменял
тут у тебя проблема в том что не зная содержимое сообщений известно как они соотносятся — в среднем отличаются всего на два бита, и если у тебя диапазон сообщений мал то просто необходимо добавить что-нить случайное туда.
кстати встречал изящную идею для одностороннего счётчика на хэшах:
берётся случайно X_0 к нему n раз применяется хеш получается X_n. (попутно проверяя на коллизии)
X_0 (начало отсчёта) собственно счётчик хранит X_i (текущее значение) и X_n (конец отсчёта)
назад счётчик не отмотать если старых значений нет и всегда можно проверить сколько осталось просто пробежав вперёд
кстати встречал изящную идею для одностороннего счётчика на хэшах:
берётся случайно X_0 к нему n раз применяется хеш получается X_n. (попутно проверяя на коллизии)
X_0 (начало отсчёта) собственно счётчик хранит X_i (текущее значение) и X_n (конец отсчёта)
назад счётчик не отмотать если старых значений нет и всегда можно проверить сколько осталось просто пробежав вперёд
вроде керберос так устроен
я же о том и говорю
Все рандомчики завязаны на компутерное время, ну ещё на что-то, что все спецы по секурити разруливают на раз.здрасти, приехали. где ты был последние 20 лет? =)
Оставить комментарий
Werdna
Есть задача шифровать число (32/64, не важно)Есть идея использовать стандартный crypt.
Вопрос, пусть есть неизвестное число X, которое закриптовали как E1=e(X). И также есть E2=e(X+1). Грубо говоря, у нас есть закриптовки двух подряд идущих чисел.
Вопрос: насколько просто это дело дешифровать, и найти ключи которыми шифруется и всётакое прочее?