— Присоединяйся к Google+!
— А что это?
— Не Фейсбук**?
— А на что оно похоже?
— На Фейсбук**!
…
— Чёрт возьми! Именно этого-то мне всегда и не хватало!
*клик*
Да в том и дело. «Сложившиеся обороты», которые явно и без очевидных причин выпадают из всеобщих правил имеют историческую тенденцию исчезать, — хотя бы в силу популяризации языка среди иностранцев.
Я не совсем слежу за темой, но недавно было некоторое количество шумихи. В сентябре 2009 вступил в силу приказ Министерства образования РФ, определяющий список словарей, грамматик и справочников, содержащих нормы современного русского литературного языка. В одном из словарей «кофе» допускает средний род. «Моё кофе» — больше не ошибка. Я не в курсе о дальнейшей судьбе приказа, но я не слышал ничего о его отмене. Но, в силе этот приказ или нет, я вполне поддерживаю эти изменения. Если на каком-то этапе напиток «кофий» мутировал в «кофе», а мужской род так и остался, то это скорее недоразумение, которое необходимо исправить, а не защищать. То же самое с «в» и «на».
Вот об этом и речь. Действительно, так сложилось что государства, названия которых совпадают с названием острова, на котором они находятся, часто получают получают предлог «на» — по инерции. Мальту, Кубу и Виргинские острова тут по всем коментариям уже затаскали до дыр. Персонально я считаю, что я еду «в Мальту», «в Кубу» и «в Виргинские острова». Но это к обсуждаемому спору не имеет особого отношения. Украина, поверьте, никогда не располагалась на одноимённом острове.
Новая Зеландия — не остров. Новая Зеландия — государство, расположенное на нескольких островах. Два самых крупных — Остров Северныйи Остров Южный. Так что пример не катит.
Аргументация «исторически сложилось» — последнее прибежище. Исторически более сложные правила с болшим количеством исключений вырастают в более простые правила с меньшим количеством исключений. Исторически сложилось, что английский Кэррола и современный отличаются, как небо и земля. Исторически сложилось, что дореволюционный русский и современный отличаются не меньше. И, уверяю Вас, что исторически сейчас складывается так, что по отношению ко всем государствам без исключения правильно говорить «в». Просто кто-то примет эту эволюцию языка раньше, а кто-то — позже. В официальном русском это уже практически состоялось.
Но, к сожалению, с ним не согласны такие титаны русской словесности как
1) А.С.Пушкин. Полтава: ”И перенес войну в Украйну”
2) Н.В.Гоголь. Страшная месть: ”Порядку нет в Украине: полковники и есаулы грызутся, как собаки, между собою.”
3) Л.Н. Толстой. Война и мир: ”… и что выгоднее всего для него отступить левее и южнее, беспокоя с фланга и тыла неприятеля и комплектуя свою армию в Украине.”
4) А.П. Чехов. Письмо И.Леонтьеву: ”Итак, я еду в Украйну, а Вы, крокодил, остаетесь в тундре”.
Не совсем понял новизну и революционность этого открытия… Если человек знает preshared key от access point-а, то он может без проблем сниффать весь траффик всех клиентов этого access point-а. Для этого ему нужно только поймать three way handshake между конкретным клиентом и access point-ом. И это уже много лет как не новость, методики отлажены, равно как и способы потиводействия.
Или тут обсуждается какая-то совсем другая ситуация?
Поражает воображение, конечно, люди вложили огромное количество сил.
Но само видео может немного сбить с толку.
Сам манёвр — пролёт через окно — был преварительно обсчитан мощными компьютерами на основании точнейшей модели, а потом долго допиливался путём проб и ошибок. Стартовое позиционирование машинки в пространстве осуществляется внешними камерами motion-capture системы. Сама машинка, разумеется, понятия не имеет ни о своём расположении в пространстве, ни о существовании каких либо окон. Всё, что она делает — это осуществляет манёвр по предпросчитанной траектории. Сам манёвр, впрочем, осуществляется автономно — данные внешних камер в неё не подаются (кроме стартового момента), машинка меряет акселерометром действующие на неё силы и корректирует вращение винтов, чтобы поддерживать эту заложенную в неё траекторию.
Хотя это всё насамом деле невероятно круто — от механики машинки до предпросчитаной модели манёвра, до автономных летающих manhacks ещё невероятно далеко (к счастью?)
Я из интереса, когда это вы устали объяснять очевидное, пролистал ваши коментарии и нашёл похожую дискуссию в начале марта. Там тоже собственно тоже состоялся разговор слепого с глухим, такой же как тянется у нас тут. Больше не буду вас утруждать. Отмечу лишь, что если мы опредилим хеширующую функцию hath(text) = text (а мы можем это сделать, так как разговор у нас изначально шёл о паролях фиксированной длины, или о входных сообщениях фиксированного размера), то E(text) = E(hash(text)) = E(hash(hash(text))).
Та кто ж со слюной требует… Мирно себе беседуем. Только вы вот растопыриваетесь, чешете самолюбие…
Я, увы, не любой первокурсник кафедры ЗИ, и ЗИ лежит довольно далеко от моих профессиональных интересов, но с удовольствием любопытствую в свободное от работы время.
Поэтому попробую порассуждать с точки зрения обывателя, а светлый венценосный гуру меня поправит, ладно?
Если взять за данность неидеальность md5 в терминах, что существуют два разных 16-байтных входных сообщения, дающие одинаковые 16-байтные значения md5, то действительно складывается впечатление, что последовательное применение md5 к собственным результатам понижает уровень энтропии, действительно можно согласиться.
Но в схеме hash(n) = md5(hash(n-1)+original_value) (где операция +, допустим, конкатенация… или даже паддинг original_value слева или справа до фиксированной длины байтами хеша с прошлого раунда) предпосылки для потерь энтропии абсолютно неочевидны… Здравый смысл где-то меня подводит?
Так в том то и дело, что понты кидать легко и приятно, в отличие от обоснованного ответа.
«Вижу бред про каскадное хеширование»… hash(n) = MD5(hash(n-1)+original_value) — это не каскадное хеширование?
А даже если MD5(MD5(...MD5(original_value))… неужели вы хотите сказать, что результат будет иметь меньше энтропии, чем MD5(original_value)? Рассматривается ситуация, когда результат функции MD5 есть 16 байт, а не строка из 32 символов, разумеется.
Объясни нам, будь добр, может тогда не будешь больше видеть бреда в комментах.
Мне казалось, что с точки зрения birthday paradox attack, или вот с точки зрения атаки на мультиколлизии из статьи ниже по ветке, каскадная функция hash(n) = MD5(hash(n-1)+original_value) не хуже (впрочем, и не лучше) оригинальной hash = MD5(original_value). Где можно было бы почитать про обратное?
И, безусловно, на MD5 в большинстве случаев проводить такие атаки не имеет смысла, потому как искомое исходное сообщение часто имеет ограничения по длине и входящим в неё символам, а не только по значению её хеша.
А с точки зрения перебора паролей по схеме пароль ---> алгоритм хеширования ---> хеш, каскадная функция линейно усложняет жизнь переборщику. Не очень впечатляет, конечно… тем более что мы так же линейно усложняем себе жизнь при проверке пароля от легального пользователя. Но зато даже хеши от пятибуквенных паролей не найдутся в Rainbow Tables и 10000 итераций делают разницу между 1 часом перебора и 1.5 годами.
Короче говоря, для аутентификации на каком-нибудь форуме схема с каскадным хешированием звучит достаточно оправданно.
Ну множество значений-то на выходе в любом случае то же самое от 00000000000000000000000000000000 до FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, если брать за данность, что ресурсы хранят в большинстве случаев MD5 от пароля. Про невозможность криптойстойкость добавлением константы — может быть, чего не знаю, того не знаю.
А есть какие-нибудь эффективные методы сузить поле перебора, обладая знанием о том, что использован такой алгоритм и, следовательно, криптостойкость пароля снижена? Дадут ли эти методы прирост в производительности перебора (сужении поля перебора), который компенсирует потери производительности проверки одного значения?
По-моему речь не шла об увеличении криптостойкости
(тем более, что её можно слегка повысить обратно, усложнив алгоритм до, например, for 0..6000 { k = md5(k + '.' + originalPassword) }, или что-то подобное)
Речь шла о том, что мы вручную сознательно увеличиваем количество времени, которое надо потратить на проверку одного значения пароля при прямом подборе, в 6000 раз.
— Присоединяйся к Google+!
— А что это?
— Не Фейсбук**?
— А на что оно похоже?
— На Фейсбук**!
…
— Чёрт возьми! Именно этого-то мне всегда и не хватало!
*клик*
** ВКонтакте?
Широко разрекламированные 250000 ещё когда будут.
Я не совсем слежу за темой, но недавно было некоторое количество шумихи. В сентябре 2009 вступил в силу приказ Министерства образования РФ, определяющий список словарей, грамматик и справочников, содержащих нормы современного русского литературного языка. В одном из словарей «кофе» допускает средний род. «Моё кофе» — больше не ошибка. Я не в курсе о дальнейшей судьбе приказа, но я не слышал ничего о его отмене. Но, в силе этот приказ или нет, я вполне поддерживаю эти изменения. Если на каком-то этапе напиток «кофий» мутировал в «кофе», а мужской род так и остался, то это скорее недоразумение, которое необходимо исправить, а не защищать. То же самое с «в» и «на».
1) А.С.Пушкин. Полтава: ”И перенес войну в Украйну”
2) Н.В.Гоголь. Страшная месть: ”Порядку нет в Украине: полковники и есаулы грызутся, как собаки, между собою.”
3) Л.Н. Толстой. Война и мир: ”… и что выгоднее всего для него отступить левее и южнее, беспокоя с фланга и тыла неприятеля и комплектуя свою армию в Украине.”
4) А.П. Чехов. Письмо И.Леонтьеву: ”Итак, я еду в Украйну, а Вы, крокодил, остаетесь в тундре”.
Или тут обсуждается какая-то совсем другая ситуация?
Но само видео может немного сбить с толку.
Сам манёвр — пролёт через окно — был преварительно обсчитан мощными компьютерами на основании точнейшей модели, а потом долго допиливался путём проб и ошибок. Стартовое позиционирование машинки в пространстве осуществляется внешними камерами motion-capture системы. Сама машинка, разумеется, понятия не имеет ни о своём расположении в пространстве, ни о существовании каких либо окон. Всё, что она делает — это осуществляет манёвр по предпросчитанной траектории. Сам манёвр, впрочем, осуществляется автономно — данные внешних камер в неё не подаются (кроме стартового момента), машинка меряет акселерометром действующие на неё силы и корректирует вращение винтов, чтобы поддерживать эту заложенную в неё траекторию.
Хотя это всё насамом деле невероятно круто — от механики машинки до предпросчитаной модели манёвра, до автономных летающих manhacks ещё невероятно далеко (к счастью?)
Я, увы, не любой первокурсник кафедры ЗИ, и ЗИ лежит довольно далеко от моих профессиональных интересов, но с удовольствием любопытствую в свободное от работы время.
Поэтому попробую порассуждать с точки зрения обывателя, а светлый венценосный гуру меня поправит, ладно?
Если взять за данность неидеальность md5 в терминах, что существуют два разных 16-байтных входных сообщения, дающие одинаковые 16-байтные значения md5, то действительно складывается впечатление, что последовательное применение md5 к собственным результатам понижает уровень энтропии, действительно можно согласиться.
Но в схеме
hash(n) = md5(hash(n-1)+original_value)(где операция +, допустим, конкатенация… или даже паддинг original_value слева или справа до фиксированной длины байтами хеша с прошлого раунда) предпосылки для потерь энтропии абсолютно неочевидны… Здравый смысл где-то меня подводит?«Вижу бред про каскадное хеширование»… hash(n) = MD5(hash(n-1)+original_value) — это не каскадное хеширование?
А даже если MD5(MD5(...MD5(original_value))… неужели вы хотите сказать, что результат будет иметь меньше энтропии, чем MD5(original_value)? Рассматривается ситуация, когда результат функции MD5 есть 16 байт, а не строка из 32 символов, разумеется.
Мне казалось, что с точки зрения birthday paradox attack, или вот с точки зрения атаки на мультиколлизии из статьи ниже по ветке, каскадная функция hash(n) = MD5(hash(n-1)+original_value) не хуже (впрочем, и не лучше) оригинальной hash = MD5(original_value). Где можно было бы почитать про обратное?
И, безусловно, на MD5 в большинстве случаев проводить такие атаки не имеет смысла, потому как искомое исходное сообщение часто имеет ограничения по длине и входящим в неё символам, а не только по значению её хеша.
А с точки зрения перебора паролей по схеме пароль ---> алгоритм хеширования ---> хеш, каскадная функция линейно усложняет жизнь переборщику. Не очень впечатляет, конечно… тем более что мы так же линейно усложняем себе жизнь при проверке пароля от легального пользователя. Но зато даже хеши от пятибуквенных паролей не найдутся в Rainbow Tables и 10000 итераций делают разницу между 1 часом перебора и 1.5 годами.
Короче говоря, для аутентификации на каком-нибудь форуме схема с каскадным хешированием звучит достаточно оправданно.
А есть какие-нибудь эффективные методы сузить поле перебора, обладая знанием о том, что использован такой алгоритм и, следовательно, криптостойкость пароля снижена? Дадут ли эти методы прирост в производительности перебора (сужении поля перебора), который компенсирует потери производительности проверки одного значения?
(тем более, что её можно слегка повысить обратно, усложнив алгоритм до, например,
for 0..6000 { k = md5(k + '.' + originalPassword) }, или что-то подобное)Речь шла о том, что мы вручную сознательно увеличиваем количество времени, которое надо потратить на проверку одного значения пароля при прямом подборе, в 6000 раз.
То-есть она и с новой фамилией не совпадает