«переименовать её в следующий формат: [КАМЕРА_ЧТО ИЗОБРАЖЕНО_КОГДА СНЯТО]. Например, на выходе название папки может превратиться из неясного «330_FUJI» в абсолютно осмысленное «FUJI-X20_Корпоратив_ноябрь_2010».»
Мне кажется если начинать с даты, то поиск становится намного удобнее.
«Есть еще такое понятие как аутентификация. Однозначно сказать, чем она отличается от верификации сказать трудно.»
Верификация — это слишком общий термин. То о чем вы рассказывает это как раз аутентификация. У вас там просто видимо исторически сложилось процесс подтверждения личности называть верификацией.
Ребят, вы чего? Я вам что всем прямо сейчас должен прямо конкретную атаку на алгоритм выложить? Моя точка зрения — аппаратная реализация в коммерческом процессоре компании, вынужденной соблюдать законы США, заслуживает гораздо меньшего доверия чем софтовая, потому что для проверки аппаратной реализации нужен реверс инжиниринг всего процессора, а софтовую реазилацию проверить вполне реально даже собственными силами. Итого имеем — плюс аппаратной реализации — быстродействие, минус — огромную трудоемкость проверки. Если за вами АНБ не следит — пользуйтесь пжалста. Потом на тюремном курорте будет считать сэкономленные секунды. :)
Обычно в криптопротоколах, соединение устанавливается во время работы, и на этапе рукопожатия устанавливаются режимы, версии алгоритма и тд. То есть если режим сменится, то пользователь может и не узнать об этом.
Изначально вы говорили что режимы влияют на стойкость ключа. А не на поиск одинаковых блоков в открытом тексте.
ЭЭЭ? Извините вы криптоанализом занимались? Если режим предназначенный для коротких сообщений используется на длинных, и в шифртекст попадает статистика открытого текста, то это позволяет со временем вскрыть сообщения. Для симметричных шифров это означает вскрытие ключа. И это не о стойкости шифра или ключа. Это о неправильном использовании алгоритма.
firewall, IPS/IDS системы
Я говорил не об крупных изменениях сетевых пакетоа, а о минимальных изменениях в служебных заголовках в пределах тонкости реализации сетевого протокола, причем количество этой информации может быть очень мелким за один раз — вплоть до 1 байта. 1 байт в служебных заголовках не обнаружт ни одна высокоуровневая система, там не будет сигнатур атаки. Опять же менятся могут скажем не tcp/up пакеты, а например ethernet, если сниффер внедрен в локалку. И это был простейший пример про сетевые пакеты. Вариантов то миллион. Попытаться передать значимую для криптоанализа информацию можно множеством способов — поиграть мощностью wi-fi, лишнюю точку при печати на принтере поставить на полях, монитором померцать, щелчком в динамике и тд. Если противник наблюдает и знает что искать — он эту информацию
получит и использует в криптоанализе.
Прочитайте хотя бы на википедии, про режимы шифрования ECB и CBC
Лучше сами почитайте и желательно не википедию. Я прекрасно знаю. И как реализуются криптоалгоритмы тоже почитайте. Вы думаете что стороны заранее все ньюансы(касательно смены режимов, например) обговаривают?
Информации в шифротексте для взлома ключа больше не станет, из-за смены режима шифрования.
Мне нравится ваша безаппеляционность. А позвольте узнать чем эти режимы отличаются? Как раз тем что в шифртексте появляется сохраняется статистика открытого текста, что и позволяет, зная специфику сообщений, гораздо успешнее проводить криптоанализ.
Слишком заметная закладка, для процессоров серийного производства.
С какого перепугу она заметная? Кому она заметная? Тем кто будет реверсить процессор?
Мой преподаватель по криптографии говорил (как раз насчет АЕС) — Утверждать что в алгоритме нет закладки на этапе его создания, можно только после того как она будет найдена и алгоритм переработан с ее учетом. Но тогда нужно начинать искать следующую.
Ну-ну. Читать-то умеем? Я не про сложность алгоритма, а про сложность криптоанализа, на которую влияют такие ньюансы, что не специалист не поверит. Но можно и на алгоритм повлиять. Предположим, аппаратная закладка переодически переводит алгоритм из основного режима CBC переводится в ECB. Результат — сообщения шифруются штатно — принимающая сторона все расшифровывает — вроде бы все ок. Но в шифртекстах становится очень много информации для вскрытия ключа. После того как статистика накапливается — ключ вскрывается. Да и в конце-концов что мешает аппаратной закладке после пытаться подмешивать ключ шифрования в служебную информацию, скажем сетевых пакетов? И вообще, чем железная реализация в процессоре отличается от программной, кроме быстродействия? Тем что ее проверить намного сложнее, обратный инжиниринг интеловских процессоров могут себе позволить очень немногие. Так что, параноикам стоит продолжать пользоваться софтовыми реализациями алгоритма.
При чем тут ключи? В железных реализациях криптоалгоритмов, можно сделать такую закладку, что ее никакой «Шнайер» не заметит, так как будет анализировать программную часть. А уязвимость зароют в каком-нибудь флаге регистра, который не участвуя в вычислениях сам по себе, будет так влиять на результат, что зная об этотм можно будет снижать сложность криптоанализа на порядки. Я как раз про ваше — «доверяем железу».
Мне кажется если начинать с даты, то поиск становится намного удобнее.
Верификация — это слишком общий термин. То о чем вы рассказывает это как раз аутентификация. У вас там просто видимо исторически сложилось процесс подтверждения личности называть верификацией.
Обычно в криптопротоколах, соединение устанавливается во время работы, и на этапе рукопожатия устанавливаются режимы, версии алгоритма и тд. То есть если режим сменится, то пользователь может и не узнать об этом.
ЭЭЭ? Извините вы криптоанализом занимались? Если режим предназначенный для коротких сообщений используется на длинных, и в шифртекст попадает статистика открытого текста, то это позволяет со временем вскрыть сообщения. Для симметричных шифров это означает вскрытие ключа. И это не о стойкости шифра или ключа. Это о неправильном использовании алгоритма.
Я говорил не об крупных изменениях сетевых пакетоа, а о минимальных изменениях в служебных заголовках в пределах тонкости реализации сетевого протокола, причем количество этой информации может быть очень мелким за один раз — вплоть до 1 байта. 1 байт в служебных заголовках не обнаружт ни одна высокоуровневая система, там не будет сигнатур атаки. Опять же менятся могут скажем не tcp/up пакеты, а например ethernet, если сниффер внедрен в локалку. И это был простейший пример про сетевые пакеты. Вариантов то миллион. Попытаться передать значимую для криптоанализа информацию можно множеством способов — поиграть мощностью wi-fi, лишнюю точку при печати на принтере поставить на полях, монитором померцать, щелчком в динамике и тд. Если противник наблюдает и знает что искать — он эту информацию
получит и использует в криптоанализе.
Лучше сами почитайте и желательно не википедию. Я прекрасно знаю. И как реализуются криптоалгоритмы тоже почитайте. Вы думаете что стороны заранее все ньюансы(касательно смены режимов, например) обговаривают?
Мне нравится ваша безаппеляционность. А позвольте узнать чем эти режимы отличаются? Как раз тем что в шифртексте появляется сохраняется статистика открытого текста, что и позволяет, зная специфику сообщений, гораздо успешнее проводить криптоанализ.
С какого перепугу она заметная? Кому она заметная? Тем кто будет реверсить процессор?