- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Какой режим лучше всего использовать при шифровании паролей (именно шифровать, а не хешировать). Пароли до 32 символов, не читабельные.
Сам склоняюсь к CFB режиму. Но часто упоминается, что для других ключей можно использовать и ECB.
И да. Где хранить вектор инициализации? Или его можно генерировать на основе открытый ключ + приватный ключ? Смысл тогда в нем?
Все что обратимо - смысла шифровать не имеет. А чем вас хеширование не устраивает?
md5(md5(pass).salt) - использовать соль не вариант в Вашем случае?
Мне нужно именно обратимо шифровать пароли. Это менеджер паролей, типа LastPass, а не учетные записи. Ключ нигде не сохраняется, кроме cookie на время сессии. Кроме того, можно использовать разные ключи для разных пасскарт.
Вот мне, почему-то кажется, что здесь лучше использовать ECB. Во-первых, не нужен вектор инициализации, который кстати тоже нежно где-то хранить, либо как-то создавать. Во-вторых, работает быстрее всех. А побочный эффект вряд ли сможет проявится. Информации то максимум 1KB.
Запутался. ECB пока использую.
Во-первых, и для расшифрования и для расшифрования по CFB требуется всего лишь зашифровывать блоки данных с помощью FK, расшифровывать их не надо. Это упрощает реализацию CFB на микроустройствах.
Во-вторых, в режиме CFB можно обрабатывать открытые тексты любой длины. Напротив, в CBC длина открытого текста должна быть кратна длине блока. Казалось бы, этот недостаток легко преодолевается выравниванием данных на границу блока перед зашифрованием и снятием выравнивания после расшифрования. При этом если полученный после расшифрования текст не удовлетворяет формату выравнивания, то логично его отбросить, а отправителю выслать сообщение об ошибке. Такая схема обработки открытых текстов произвольной длины была применена в старых версиях SSL/TLS и оказалась уязвимой! Оказалось, что противник может расшифровать любой шифртекст, используя другие специально подобранные шифртексты и анализируя сообщения о нарушениях формата их выравнивания после расшифрования. В последних версиях TLS выравнивание сохранено, но сообщение о нарушении формата выравнивания не отсылается.
В-третьих, в режиме CFB достаточно обеспечить уникальность синхропосылки, обеспечивать ее непредсказуемость не требуется. В CBC ситуация другая. В старых версиях SSL/TLS синхропосылка при CBC-зашифровании очередного пакета данных синхропосылка определялась как последний блок шифртекста из предыдущего пакета и, таким образом, была известна противнику. Оказалось, что противник может использовать знание синхропосылки для проверки того, что перехваченному блоку шифртекста соответствует открытый текст с определенным значением. Правда для этого противник должен иметь возможность навязывать открытый текст, который будет передан в очередном пакете. Тем не менее, в последних версиях TLS синхропосылка выбирается как случайное и, следовательно, непредсказуемое слово.
Слабости CBC были использованы и в недавней атаке Риццо и Дуонга на SSL/TLS. Об этой атаке мы поговорим немного позже.
Выбираем CFB?
Источник