протоколы CHAP и MS-CHAP не передают текст пароля в открытом виде — только свертку со
случайным числом (схема Challenge-Response), поэтому для аутентификации внешней программой ты сможешь использовать только PAP…
… а это очень плохо в плане угрозы прослушивания сети
При любой попытке отодвинуться дальше точки начала натяжения «колечек», клавиатура дико норовила вернуться в исходное положение :-(
Поэтому приходилось держать ее левой рукой, а правой набирать команды. Так что Ваша версия не очень…
это для маршрутизаторов, а они у Циски (да впрочем и у других вендоров) могут
— файрволить
— NAT-ить
— шифровать
— подсчитывать
— классифицировать по приоритетам
Идея безусловно хорошая, однако, несовсем ясно, с каким упреждением берется прогноз для проверки совпадений, и вообще формула расчета.
Мне кажется, было бы очень интересно проанализировать те же сервисы по тем же городам, но ровно с 7-дневным горизонтом прогноза (т.е. сравнить их прогнозы на сегодня, выдававшиеся 26 января).
Это экстенсивный путь. Да, на первое время он будет наверное достаточно стойким.
Но обычно, когда обнаружена структурная (идеологическая) ошибка в криптоалгоритме,
стараются изменить именно идеологию его построения (комбинирования
математических выражений, входящих в него).
На самом деле, как только завершится SHA-3 и победитель будет назван,
его ждет такой же успех как AES на сегодняшний день.
Ждать нового алгоритма осталось недолго. Вот хорошая ссылка про конкурс: ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
Вы приводите пример атаки класса генерации коллизий, а не обращения.
В первом разделе заметки акцентировано внимание на разнице между этими типами атак.
Для быстрого создания коллизии он должен иметь возможность в процессе подбора менять и первый документ и второй. Если первый документ менять нельзя, то процесс затянется очень надолго (вне доступных пределов).
Вопрос к тем, кто приводил примеры ситуации, когда пара «закрытый/открытый ключ» генерируется на серверной стороне. Если можно, приведите примеры провайдеров криптоуслуг, которые делают это именно так?
Я себе процесс получения сертификата представляю следующим образом:
1) Вы заходите на сайт, представляющий услуги выдачи сертификатов
2) на ЛОКАЛЬНОЙ машине Вашим локальным криптопровайдером генерируется пара «закрытый/открытый ключ» (причем, этот процесс может происходить и в CPU крипто-токена, например, USB-брелока, которого закрытый ключ вообще никогда ни при каких условиях не покидает)
3) открытый ключ от только что созданной пары пересылается на сервер (защищает его от подделки в этот момент HTTPS);
4) сервер подписывает присланный открытый ключ своей ЭЦП, создавая собственно СЕРТИФИКАТ ключа подписи;
5) сервер отсылает сертификат Вам (и если хочет, то может положить его в свое хранилище для кэширования)
В данном случае несколько сильнее.
ОДНОВРЕМЕННЫХ коллизий одной и той же пары сообщений на MD5 и например, SHA-0, пока нет, и мне кажется это весьма и весьма трудоемко.
Да, совершенно верно, я умышленно не упоминал о Rainbow tables, чтобы не перегружать материал.
Именно из-за их существования все переходят на обязательное использование «соли» (salt) при хешировании паролей — в этом случае радужные таблицы станвоятся бесполезными.
разрядность ГОСТ Р 34.11 — 256 бит,
по парадоксу дней рождения придостаточном объеме дискового пространства
достаточно 2^(256/2) т.е. 2^128 операций для поиска коллизии,
раз австрийцы улучшили на 2^23 получается 2^(128-23)=2^105,
об этой атаке и упоминается в заметке.
Это нереализуемо на практике и имеет смысл пока только в теории
п. 2.1.2.1
?
протоколы CHAP и MS-CHAP не передают текст пароля в открытом виде — только свертку со
случайным числом (схема Challenge-Response), поэтому для аутентификации внешней программой ты сможешь использовать только PAP…
… а это очень плохо в плане угрозы прослушивания сети
Поэтому приходилось держать ее левой рукой, а правой набирать команды. Так что Ваша версия не очень…
— файрволить
— NAT-ить
— шифровать
— подсчитывать
— классифицировать по приоритетам
Мне кажется, было бы очень интересно проанализировать те же сервисы по тем же городам, но ровно с 7-дневным горизонтом прогноза (т.е. сравнить их прогнозы на сегодня, выдававшиеся 26 января).
я только один #define внутрь занес для наглядности.
...
memcpy(u, state, sizeof(u));
memcpy(v, data, sizeof(v));
for (i = 0; i < 8; i += 2) {
X(w, u, v); \
P(key, w); \
R(key, h, i, t, l, r); \
S(s, l, r); \
if (i != 6) { \
A(u, l, r); \
if (i == 2) { \
C(u); \
} \
AA(v, l, r); \
}
}
SHIFT12(u, m, s);
SHIFT16(h, v, u);
SHIFT61(h, v);
...
Похоже, что Вы абсолютно правы.
Может кто-то еще прокомментирует такой вариант?
Но обычно, когда обнаружена структурная (идеологическая) ошибка в криптоалгоритме,
стараются изменить именно идеологию его построения (комбинирования
математических выражений, входящих в него).
На самом деле, как только завершится SHA-3 и победитель будет назван,
его ждет такой же успех как AES на сегодняшний день.
Ждать нового алгоритма осталось недолго. Вот хорошая ссылка про конкурс:
ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo
В первом разделе заметки акцентировано внимание на разнице между этими типами атак.
Я себе процесс получения сертификата представляю следующим образом:
1) Вы заходите на сайт, представляющий услуги выдачи сертификатов
2) на ЛОКАЛЬНОЙ машине Вашим локальным криптопровайдером генерируется пара «закрытый/открытый ключ» (причем, этот процесс может происходить и в CPU крипто-токена, например, USB-брелока, которого закрытый ключ вообще никогда ни при каких условиях не покидает)
3) открытый ключ от только что созданной пары пересылается на сервер (защищает его от подделки в этот момент HTTPS);
4) сервер подписывает присланный открытый ключ своей ЭЦП, создавая собственно СЕРТИФИКАТ ключа подписи;
5) сервер отсылает сертификат Вам (и если хочет, то может положить его в свое хранилище для кэширования)
Закрытый ключ Ваш компьютер не покидал !!!
ОДНОВРЕМЕННЫХ коллизий одной и той же пары сообщений на MD5 и например, SHA-0, пока нет, и мне кажется это весьма и весьма трудоемко.
Среднее время на проверку 1 пароля — примерно 0.1 секунды.
Очень удачное на мой взгляд решение.
Именно из-за их существования все переходят на обязательное использование «соли» (salt) при хешировании паролей — в этом случае радужные таблицы станвоятся бесполезными.
разрядность ГОСТ Р 34.11 — 256 бит,
по парадоксу дней рождения придостаточном объеме дискового пространства
достаточно 2^(256/2) т.е. 2^128 операций для поиска коллизии,
раз австрийцы улучшили на 2^23 получается 2^(128-23)=2^105,
об этой атаке и упоминается в заметке.
Это нереализуемо на практике и имеет смысл пока только в теории