Сейчас приходится писать php страничку с возможностью авторизации и прочее.
Задумался насчет возможности взлома этого алгоритма при известном векторе инициализации(32 символа), и ключе, который представляет из себя хэщ whirlpool, от некоторой информации, которая со временем изменяется.
За что можно очень сильно меня покарать - шифруются всегда одни и те же данные.

Реально ли задать новый вектор инициализации, не расшифровывая текст? Информации кодируется не так уж и много.

зы с криптографией лицом к лицу столкнулся в первый раз, так что я криптодевственник можно сказать. Ну или уже нет

| Сообщение посчитали полезным:

Зачем тебе там вообще аес? От каких угроз защищаешься?
AES в каком режиме работает?

-----
старый пень

| Сообщение посчитали полезным:

r_e пишет:
Зачем тебе там вообще аес? От каких угроз защищаешься?
Паранойа + возможность sql инъекции(работаю над устранением) Система управления мониторами, освещением для филиала одной организации, которая владеет очень многим. Филиалы есть в каждом городе.

r_e пишет:
AES в каком режиме работает?
OFB.

| Сообщение посчитали полезным:

Dart Sergius
Что касается сикля, то непонятно каким боком там АЕС.

В ОФБ режиме Ключ+ИВ дают гамму. Соответственно, перешифровать можно элементарно.
New = Old ^ (OFB(K, OldIV) ^ OFB(K, NewIV))

-----
старый пень

| Сообщение посчитали полезным: Dart Sergius, Abraham

r_e пишет:
Что касается сикля, то непонятно каким боком там АЕС.
быдлокодерство оно карает
r_e пишет:
перешифровать можно элементарно
K - ключ? А если его не знаешь, а он - 64 символа, и ключ этот меняется раз в час допустим, то за час перешифровать никак?

зы самостоятельно начинаю осиливать крипто.

| Сообщение посчитали полезным:

Если б можно было перешифровать не зная ключ, то на кой такой шифр вообще нужен?

-----
старый пень

| Сообщение посчитали полезным: DimitarSerg

1 - из всех поточных режимов стоит использовать только CTR
2 - никогда не шифруй два разных текста одной гаммой. в режиме CTR можно задать случайное начальное значение счетчика и хранить его вместе с зашифрованным сообщением.
3 - перешифровать элементарно. расшифровать и зашифровать. ключ естественно надо знать.
4 - если помимо шифрования нужен контроль целостности сообщений, нужно использовать HMAC, либо специальные режимы authenticated encryption (CCM, OCB, GCM)

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: Dart Sergius

ntldr
Не могли бы Вы подробней осветить изложенные замечания?
1. С чего бы вдруг CTR был бы более стойкий чем OFB? Только за счет рандомного значения счетчика? Дык OFB можно посолить немного.
2. Почему два? Ну получишь ты M1 ^ M2 и что? Вот если хотя бы 3 сообщения одной гаммой - тогда да.

-----
старый пень

| Сообщение посчитали полезным:

В общем одной гаммой у меня ничего шифроваться не будет. Повторений векторов инициализаций не будет, а whirpool от некоторой величины, которая со времен меняется(ключ временный, коим все шифруется), не даст за вменяемые сроки раскрыть ключ, и перешифровать всю информацию с другим вектором. А я не думаю что при шифротексте байтов в 32, а то и больше(информация авторизации). Ну и я не слышал чтобы вскрывали whirpool.
Так что все что можно шифром накрыл с 512 битным ключем. Думаю проблем с атакой не возникнет.

ps Спасибо, вы меня успокоили-)

| Сообщение посчитали полезным:

r_e пишет:
1. С чего бы вдруг CTR был бы более стойкий чем OFB?
CTR более простой режим с наиболее изученными свойствами. У OFB гамма теоретически может зацикливаться в периоде меньшем чем 2^block_size, либо может произойти линеаризация и ухудшиться стойкость при наличии серьезных дефектов в шифре, у CTR это исключено. Еще существенным плюсом CTR является легкость параллелизации и произвольный доступ к блокам сообщения.

r_e пишет:
2. Почему два? Ну получишь ты M1 ^ M2 и что? Вот если хотя бы 3 сообщения одной гаммой - тогда да.
Зная что-нибудь о M1 можно узнать и о M2 и наоборот. Что это дает в конкретном случае зависит от применения, может быть у нас M1 станет целиком известен атакующему.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

ntldr
По поводу второго замечание нельзя не согласиться.
Что касается первого, не скинешь ссылок на отчеты по этой проблеме?
Насколько я вижу, что OFB, что CTR имеют одно ядро. Поскольку AES считается стойким, то PRNG на его основе тоже "стойкий". В связи с этим зацикливания должны быть в пределах стандартов на генераторы.
IV у CTR в два раза меньше. CTR легко распараллелить.
Или ты про общий случай (не АЕС)?

-----
старый пень

| Сообщение посчитали полезным:

Общий случай для произвольного шифра: допустим при шифровании блочный шифр преобразует открытый текст в шифртетекст такими парами: a->b, b->c, c->d, d->a, тогда получение любого члена этой последовательности порождает короткий цикл и создает дополнительную уязвимость которой не обладает применяемый шифр. Уже не помню точно оценку этой вероятности, но она ощутимо ниже 1/2^block_size. Это особенно актуально для старых шифров с 64 битным блоком (можно реально поймать короткий цикл на потоках всего в гигабайты), но и для современных шифров со 128 битным блоком эта уязвимость может сработать если сильно неповезет.

Уязвимость с линеаризацией работает если применяемый шифр обладает такими свойствами, что повторное зашифрование данных тем-же ключом ухудшает его стойкость (создает какие-либо различители). Такие свойства могут быть неожиданно обнаружены и у AES, их отсутствие никто не доказал.
Это большей частью теоретические уязвимости, разве что кроме циклов в шифрах с 64 битным блоком, которые вполне могут быть где-нибудь использованы, но сама возможность получения таких уязвимостей уже достаточна чтобы нигде не использовать OFB.

r_e пишет:
Поскольку AES считается стойким, то PRNG на его основе тоже "стойкий". В связи с этим зацикливания должны быть в пределах стандартов на генераторы.
Современные стандарты PRNG на блочном шифре используют именно CTR. OFB использовать в этом применении крайне нежелательно, так как зацикливание это проблема самого режима шифрования. Оно может возникнуть даже с идеальным шифром внутри.
У CTR длина цикла всегда равна 2^(block_size/2), достаточно лишь следить чтобы длина потока не вышла за этот предел. Т.е. в случае AES-CTR на одном ключе может быть безопасно зашифровано 2^64 сообщений, длиной до 2^64 каждое. Думаю этого вполне достаточно для любых применений.

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: r_e, Dart Sergius

проблема решена

| Сообщение посчитали полезным: