Обновить
182
0
Алексей@Scratch

Системный архитектор, криптоманьяк

Отправить сообщение
рыба гниет с головы
Такие как топик кастер для такой конторы как вконтакт — капля в море, ей(конторе) не то что насрать (там ведь тоже как никак тужиться надо), ей вообще похуй на тех, кто приносит им копейки. Они живут за счет миллионов леммингов, готовых вложить реал в красивые пнгшки, циферки и прочую ничего не значащую хрень. А если кто-то(разработчик) решит пооткусывать от этого пирога, то велкам забашлять сумму, которая убедит начальство не чихать в вашу сторону.
вы ничего не сказали о том, как может снижаться стойкость при использовании раундовой соли или других ухищрений вроде aes, как например тут:
code.google.com/p/paranoim/source/browse/trunk/ParanoIM/src/com/paranoim/crypto/utils/SlowHasher.java
так что поднимать панику рано
Можно, кстати, спросить у разработчика планируют ли они вводить unsigned типы ) Думаю, тема наболевшая у многих работающих с байтиками людей
Спасибо Вам и собеседнику, интересный подкаст о внутренностях JVM.
Я вообще то не говорил что замедляет хэширование именно раундовая соль, она призвана помочь с коллизиями. А насчет винрара — в исходниках unrar в crypt.cpp есть отличные строки (не зря я его упоминал)
const int HashRounds=0x40000;
for (int I=0;I<HashRounds;I++)
{
hash_process( &c, RawPsw, RawLength, HandsOffHash);

можете сами глянуть…
Можете кинуть такой ссылкой? Чет я по SHA-3 requirements никак не найду доку в которой был бы пункт 2.2.1 )
всякие пермутации призваны усложнить как раз таки их поиск… Хотя с удовольствием почитаю о безитеративном замедлении
на самом деле первый дельный комментарий к топику ) Я пока не знаю что ответить, надо почитать литературу
кому надо могут сгенерить таблицы и для определенного saltа, если подбирается лишь определенный пароль. Я правда не знаю будет ли это быстрее чем голый брут
для успокоения души можно провести тесты генерируемой соли на случайность )
прикольный вариант ) не сразу сообразил как работает
0x означает, что используется 16ричная кодировка
генерируем хеш (соль+пароль). Соль хранится отдельно. Чтобы проверить верен ли пароль, мы обязаны провторить процесс как хеш(соль+проверяемый пароль) и если они совпадут то ок.
Отсюда вывод — соль хранится отдельно и ни от кого не прячется
Говоря о шифровании, можно не добавлять к исходному сообщению никаких специальных данных (Padding), по которым можно узнать зашифрованы данные или нет. Тогда если данные, например, пожаты хорошим алгоритмом (без сигнатур, опять же) или обфусцированы как в скайпе, то на выходе даже с верным паролем данные не будут отличимы от случайных.
мы не рассматриваем ситуацию когда надо еще что то достать (соль, кстати, ни разу не секретная часть)
Мы рассматриваем ситуацию когда у нас уже всё есть кроме пароля
Я имел в виду типы для работы с числами. Про двухбайтовый char в курсе.
В основном это используется на клиентских машинах для шифрования различной инфы (архивы\документы и.т.д)
Если в итоге все перейдут на нормальные секьюрные алгоритмы, то это будут очень даже хорошие последствия. Давно пора.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность