Использование after в синтезируемом коде — это плохо, потому что:
1. Вы смешиваете functional simulation и gate-level simulation (который после P&R). Задача первого — убедиться, что Ваш алгоритм правильный, второго — что суровая физическая реальность не разрушит Ваш правильный алгоритм. Если gate-level simulation выполняется слишком медленно, то стоит посмотреть в сторону timing analysis (у Altera это, если не ошибаюсь, TimeQuest): он укажет Вам, в каких именно местах могут быть проблемы с временными характеристиками (плюс компилятор может использовать эту информацию для оптимизации схемы).
2. Возможности повторного использования Вашего кода сильно ограниченны, поскольку он не инвариантен относительно частоты: при 10 МГц задержка 1 ns — это почти дельта-задержка (в том плане, что она мала по сравнению с периодом), на частоте 100 МГц — уже чувствительно, а на 1 ГГц — целый такт. В зависимости от заданной частоты работы схемы functional simulation будет давать очень разные результаты, и это явно не то, к чему Вы стремитесь. Ну и никакого физического обоснования для константы 1 ns нет, все будет зависеть от модели ПЛИС.
Сертифицированных средств защиты для Linux немного: слишком узкая ниша и высокая стоимость сертификации. Думаю, можно посмотреть в сторону сертифицированного дистрибутива (варианты есть на http://www.linuxcenter.ru/shop/sertified_fstek). Настраивать терминальные серверы и рабочие станции, скорее всего, придется руками: я не знаю, входят ли пакеты LTSP в состав сертифицированного решения и что прописано в эксплуатационной документации об установке стороннего ПО.
На всякий случай напоминаю, что по линии ФСТЭК России и ФСБ России сертификация осуществляется поэкземплярно (для ФСТЭК России это подтверждается номерной голограммой на дистрибутиве ПО). Поэтому то, что дистрибутив прошел сертификацию, еще не означает, что именно Ваш экземпляр сертифицирован.
PS На сайте ФСТЭК России есть полный реестр сертифицированных СЗИ, можете покопаться в нем (http://fstec.ru/component/attachments/download/489).
PPS Нашел интересный обзор по теме СЗИ для Линукс: http://www.aladdin-rd.ru/company/pressroom/articles/41672.
>> Это одни из НЕМНОГИХ историй успеха, о которых мы решили написать в статье.
Надеюсь, все же из МНОГИХ, а то какой-то черный пиар получается. Или вы просто заранее предупреждаете?
Я бы внимательно почитал договор с банком. Обычно в нем пишется о подтверждении транзакций, CVV2/CVC2, необходимости держать данные карты в тайне и т.д. С высокой долей вероятности вы сможете опротестовать платеж с неверным CVV2/CVC2 (хотя, опять же, все зависит от условий договора). Только не забывайте, что опротестование валидных платежей может рассматриваться как мошенничество (со всеми вытекающими), если будет доказано, что платеж действительно осуществлен вами.
Эмм… Странно, что ниже Вы просите привести критику. Мне казалось, что все обсуждение выше — это, собственно, и есть критика.
Давайте кратко по пунктам:
1. Отсутствие преимуществ перед известными методами при наличии недостатков.
2. Отсутствие преимуществ перед передачей исходного сообщения без использования стеганографии (не обеспечивается факт скрытой передачи).
3. Ограниченная область применения в связи с низкой скоростью.
4. Недостаточная строгость формулировок в статье, из-за чего возникли варианты двойного толкования в комментариях (это затрудняет обсуждение, но на сам метод, разумеется, не влияет).
Почитайте название. там есть фраза «очень медленная».
Вы спросили, что мне мешает использовать по картинке на каждое слово, я ответил.
Я не приводил методы сравнения чем хуже, а чем лучше.
Изобретать что-то, что во всех отношениях хуже имеющихся аналогов, немного бессмысленно. Следовательно, должны быть какие-то сильные стороны — вот про них и хотелось услышать.
Простите, не понял. Как именно? в каком контейнере?
Да без контейнера! Если уж следовать Кашену, то злоумышленник знает способ встраивания (см. цитату из его работы выше) и без труда восстановит последовательность хешей. Также напомню, что «так и не может научное сообщество решить, что считать «подозрительным», а что не считать…» (это Ваш ответ), поэтому не вижу отличий в передаче последовательности изображений или последовательности байтов.
Я не хочу вас обижать… Но это не верно. Во первых не естественным образом, а во-вторых не равномерное.
Вы вибираете изображения с определенным хешем, я — с определенным распределением и значениями младших битов (исходное сообщение предварительно зашифрую на константном ключе, чтобы поправить его статистику). Принципиальных отличий так и не увидел.
Наконец, если уж говорить о секретности по Кашену, то в вашей системе между пустым и заполненным стегоконтейнерами существует одно огромное отличие: длина пустого контейнера равна нулю, заполненного — количеству байтов (если считать длину контейнера в изображениях). Так что тезис о совершенной секретности тоже не выполняется.
PS Если единственный минус на моем комментарии от Вас, то это выглядит как-то неприлично, дискуссия все же. Если же от другого хабраюзера, то я призываю присоединиться к обсуждению и высказать, чем вызван минус.
При конечном выходном алфавите Ваш подход вырождается в шифр простой замены
Так у меня бесконечный алфавит. Что мешает вам в >2015 году выгрузить по одной сущности на каждое слово?
С бесконечным алфавитом конструкция напоминает шифр Вернам
Мое множество конечное
Павел, кажется, я только что испытал мощнейший когнитивный диссонанс. Определитесь, пожалуйста, конечный ли у Вас выходной алфавит. Всё же конечное и бесконечное множества имеют строгие математические определения, а в статье была претензия на мат. модель.
Что мешает вам в >2015 году выгрузить по одной сущности на каждое слово?
Необходимость спрятать 1 Гб данных. По картинке на каждый байт — это миллиард изображений. Миллиард, Карл! А перебрать придется в худшем случае (все байты сообщения одинаковые) порядка 256×109 изображений (для таких формул LaTeX не нужен). В то же время, запрятать 1 Гб данных в 500 Гб HD-видео вполне можно.
Кроме того, объясните мне, пожалуйста:
1. Чем хеш-стеганография лучше метода LSB? Могу предложить сразу два варианта LSB: либо шифровать данные перед встраиванием и использовать контейнеры, у которых младшие биты естественным образом имеют равномерное распределение, либо подбирать контейнеры, у которых определенные младшие биты уже совпадают с сообщением.
2. Почему я не могу сообщение из вашего примера передать безо всяких котиков просто в виде 0x55 0хD1 0x34 0х23 0x75 0х98? В чем принципиальное отличие?
Также напомню, что по Кошену the embedding function F and the distributions of all random variables are known to Eve, т.е. злоумышленник знает способ встраивания, given a covertext distribution, the embedding function F is universal for information embedding, т.е. способ встраивания не зависит от распределения встраиваемых сообщений, и the key has been chosen at random and communicated over a secure channel prior to the use of the stegosystem, т.е. ключ (если Вы будете его использовать) выбирается независимо от сообщения.
PS (с надеждой) Это ведь не кандидатская диссертация в МГТУ, правда?
Потому и не рассматриваются, что бесконечный алфавит — это математическая абстракция, не достижимая в реальности.
С бесконечным алфавитом конструкция напоминает шифр Вернама, поскольку P(c=b) = P(c=b | m=a) = 0.
При конечном выходном алфавите Ваш подход вырождается в шифр простой замены: каждому символу открытого текста ставится в соответствие определённое конечное множество, из которого случайным образом выбирается один представитель. Имея достаточный объем шифртекстов, такой алгоритм можно ломать частотным анализом.
Для random.org даже хеш не нужен, этот сайт выдаёт истинно случайные последовательности.
То, что Вы описываете, больше похоже на шифр подстановки с бесконечным выходным алфавитом (почему, собственно, такие шифры и не рассматриваются в классической криптографии).
Тогда предлагаю передавать исходное сообщение, назвав его выгрузкой с random.org. В принципе, не более подозрительно, чем длинная череда котиков (хомячков, голых женщин).
Поздравляю, Павел, Вы изобрели шифр простой замены. При бесконечном множестве котиков получается что-то, отдалённо напоминающее шифр Вернама. Но стеганография ли это?
Уважаемый потенциальный Папа Римский, задумайтесь о возможностях, которые открываются, когда одни программы могут автоматизированно (и осмысленно) изменять другие программы.
[sarcasm] Тогда мы сможем писать трансляторы и полиморфные вирусы! [/sarcasm]
Мне кажется, автор вплотную подошел к написанию либо курсовой работы, либо дипломного проекта. Навскидку предложенная (довольно сырая, надо сказать) концепция обладает несколькими серьезными недостатками.
Самый очевидный — это зацикливание: если обработчик события «переменная равна точно X» не изменяет значение X, то он будет выполняться вечно. Следующий случай зацикливания — обработчик A запускается при изменении X и меняет Y, обработчик B запускается при изменении Y и меняет X. Чтобы отловить такие ситуации в статике, необходимо построить полный граф конечного автомата, а он для любой более-менее серьезной программы будет ОЧЕНЬ большим.
Отказ от ветвлений и циклов заставляет все такие конструкции преобразовывать в обработчики событий, а все локальные переменные переносить в глобальную область видимости и сопоставлять с обработчиками. Производительность системы будет не просто низкой, а сверхнизкой; заодно и требования к памяти непомерно вырастут. Управлять (в терминах разработки) таким количеством обработчиков тоже будет непросто.
Проблему отслеживания связей «ситуационно-ориентированное программирование» тоже не решает: изменение одного обработчика по-прежнему слабо предсказуемо влияет на работу остальной части программы. Того же самого эффекта можно достичь в структурном программировании применением средств статического анализа кода (ресурсоемкость опускаю) и/или аккуратного документирования всех побочных эффектов функций.
В изложенном подходе ничего принципиально нового не обнаружилось: достаточно посмотреть на системы моделирования годов так 80-х прошлого века. Навскидку парадигма «ситуационно-ориентированного программирования» была реализована в языке VHDL (1983+, если верить вики).
Обработчики событий называются в нем процессами (process), состояние хранится в сигналах (signal). Процесс запускается при изменении одного из сигналов, к которым привязан процесс; значения измененных в процессе сигналов обновляются в момент завершения процесса. Все процессы выполняются параллельно и мгновенно (абстракция виртуальной машины VHDL). Каждый сигнал может изменяться только одним процессом, что частично снимает проблему конкурентного изменения состояния. Зацикливание выявляется в рантайме (нет, мы не будем решать проблему останова).
Следует учитывать, что в VHDL не отказались ни от ветвлений, ни от циклов: в противном случае написание кода стало бы адом для программиста. Кроме того, процесс может хранить свое внутреннее состояние в локальных переменных (на них, кстати, обработчики событий навесить нельзя): это также сокращает объем кода и разгружает глобальную область видимости.
Чтобы сделать код модульным и управляемым, в VHDL поддерживаются дополнительный уровень абстракции в виде функциональных блоков (entity), все общение между которыми происходит только путем изменения входных и выходных сигналов.
В современном варианте тот же подход реализуется конечными автоматами (привет, case) в простых случаях или паттернами типа publisher/subscriber и message broker'ами — в более сложных.
Вспомнилось, как на экзамене по алгебраическим системам один из студентов строил поле F6 (sic!): 0, +1, -1, +2, -2… А что ставить перед 3 — плюс или минус — он решить так и не сумел, после чего благополучно покинул экзамен :)
1. Вы смешиваете functional simulation и gate-level simulation (который после P&R). Задача первого — убедиться, что Ваш алгоритм правильный, второго — что суровая физическая реальность не разрушит Ваш правильный алгоритм. Если gate-level simulation выполняется слишком медленно, то стоит посмотреть в сторону timing analysis (у Altera это, если не ошибаюсь, TimeQuest): он укажет Вам, в каких именно местах могут быть проблемы с временными характеристиками (плюс компилятор может использовать эту информацию для оптимизации схемы).
2. Возможности повторного использования Вашего кода сильно ограниченны, поскольку он не инвариантен относительно частоты: при 10 МГц задержка 1 ns — это почти дельта-задержка (в том плане, что она мала по сравнению с периодом), на частоте 100 МГц — уже чувствительно, а на 1 ГГц — целый такт. В зависимости от заданной частоты работы схемы functional simulation будет давать очень разные результаты, и это явно не то, к чему Вы стремитесь. Ну и никакого физического обоснования для константы 1 ns нет, все будет зависеть от модели ПЛИС.
На всякий случай напоминаю, что по линии ФСТЭК России и ФСБ России сертификация осуществляется поэкземплярно (для ФСТЭК России это подтверждается номерной голограммой на дистрибутиве ПО). Поэтому то, что дистрибутив прошел сертификацию, еще не означает, что именно Ваш экземпляр сертифицирован.
PS На сайте ФСТЭК России есть полный реестр сертифицированных СЗИ, можете покопаться в нем (http://fstec.ru/component/attachments/download/489).
PPS Нашел интересный обзор по теме СЗИ для Линукс: http://www.aladdin-rd.ru/company/pressroom/articles/41672.
Надеюсь, все же из МНОГИХ, а то какой-то черный пиар получается. Или вы просто заранее предупреждаете?
Давайте кратко по пунктам:
1. Отсутствие преимуществ перед известными методами при наличии недостатков.
2. Отсутствие преимуществ перед передачей исходного сообщения без использования стеганографии (не обеспечивается факт скрытой передачи).
3. Ограниченная область применения в связи с низкой скоростью.
4. Недостаточная строгость формулировок в статье, из-за чего возникли варианты двойного толкования в комментариях (это затрудняет обсуждение, но на сам метод, разумеется, не влияет).
PS Сорри, из-за плевка в карму теперь не могу использовать теги.
Вы спросили, что мне мешает использовать по картинке на каждое слово, я ответил.
Изобретать что-то, что во всех отношениях хуже имеющихся аналогов, немного бессмысленно. Следовательно, должны быть какие-то сильные стороны — вот про них и хотелось услышать.
Да без контейнера! Если уж следовать Кашену, то злоумышленник знает способ встраивания (см. цитату из его работы выше) и без труда восстановит последовательность хешей. Также напомню, что «так и не может научное сообщество решить, что считать «подозрительным», а что не считать…» (это Ваш ответ), поэтому не вижу отличий в передаче последовательности изображений или последовательности байтов.
Вы вибираете изображения с определенным хешем, я — с определенным распределением и значениями младших битов (исходное сообщение предварительно зашифрую на константном ключе, чтобы поправить его статистику). Принципиальных отличий так и не увидел.
Наконец, если уж говорить о секретности по Кашену, то в вашей системе между пустым и заполненным стегоконтейнерами существует одно огромное отличие: длина пустого контейнера равна нулю, заполненного — количеству байтов (если считать длину контейнера в изображениях). Так что тезис о совершенной секретности тоже не выполняется.
PS Если единственный минус на моем комментарии от Вас, то это выглядит как-то неприлично, дискуссия все же. Если же от другого хабраюзера, то я призываю присоединиться к обсуждению и высказать, чем вызван минус.
Необходимость спрятать 1 Гб данных. По картинке на каждый байт — это миллиард изображений. Миллиард, Карл! А перебрать придется в худшем случае (все байты сообщения одинаковые) порядка 256×109 изображений
(для таких формул LaTeX не нужен). В то же время, запрятать 1 Гб данных в 500 Гб HD-видео вполне можно.Кроме того, объясните мне, пожалуйста:
1. Чем хеш-стеганография лучше метода LSB? Могу предложить сразу два варианта LSB: либо шифровать данные перед встраиванием и использовать контейнеры, у которых младшие биты естественным образом имеют равномерное распределение, либо подбирать контейнеры, у которых определенные младшие биты уже совпадают с сообщением.
2. Почему я не могу сообщение из вашего примера передать безо всяких котиков просто в виде 0x55 0хD1 0x34 0х23 0x75 0х98? В чем принципиальное отличие?
Также напомню, что по Кошену the embedding function F and the distributions of all random variables are known to Eve, т.е. злоумышленник знает способ встраивания, given a covertext distribution, the embedding function F is universal for information embedding, т.е. способ встраивания не зависит от распределения встраиваемых сообщений, и the key has been chosen at random and communicated over a secure channel prior to the use of the stegosystem, т.е. ключ (если Вы будете его использовать) выбирается независимо от сообщения.
PS (с надеждой) Это ведь не кандидатская диссертация в МГТУ, правда?
С бесконечным алфавитом конструкция напоминает шифр Вернама, поскольку P(c=b) = P(c=b | m=a) = 0.
При конечном выходном алфавите Ваш подход вырождается в шифр простой замены: каждому символу открытого текста ставится в соответствие определённое конечное множество, из которого случайным образом выбирается один представитель. Имея достаточный объем шифртекстов, такой алгоритм можно ломать частотным анализом.
То, что Вы описываете, больше похоже на шифр подстановки с бесконечным выходным алфавитом (почему, собственно, такие шифры и не рассматриваются в классической криптографии).
[sarcasm] Тогда мы сможем писать трансляторы и полиморфные вирусы! [/sarcasm]
Smalltalk, Erlang, SOA?
Самый очевидный — это зацикливание: если обработчик события «переменная равна точно X» не изменяет значение X, то он будет выполняться вечно. Следующий случай зацикливания — обработчик A запускается при изменении X и меняет Y, обработчик B запускается при изменении Y и меняет X. Чтобы отловить такие ситуации в статике, необходимо построить полный граф конечного автомата, а он для любой более-менее серьезной программы будет ОЧЕНЬ большим.
Отказ от ветвлений и циклов заставляет все такие конструкции преобразовывать в обработчики событий, а все локальные переменные переносить в глобальную область видимости и сопоставлять с обработчиками. Производительность системы будет не просто низкой, а сверхнизкой; заодно и требования к памяти непомерно вырастут. Управлять (в терминах разработки) таким количеством обработчиков тоже будет непросто.
Проблему отслеживания связей «ситуационно-ориентированное программирование» тоже не решает: изменение одного обработчика по-прежнему слабо предсказуемо влияет на работу остальной части программы. Того же самого эффекта можно достичь в структурном программировании применением средств статического анализа кода (ресурсоемкость опускаю) и/или аккуратного документирования всех побочных эффектов функций.
В изложенном подходе ничего принципиально нового не обнаружилось: достаточно посмотреть на системы моделирования годов так 80-х прошлого века. Навскидку парадигма «ситуационно-ориентированного программирования» была реализована в языке VHDL (1983+, если верить вики).
Обработчики событий называются в нем процессами (process), состояние хранится в сигналах (signal). Процесс запускается при изменении одного из сигналов, к которым привязан процесс; значения измененных в процессе сигналов обновляются в момент завершения процесса. Все процессы выполняются параллельно и мгновенно (абстракция виртуальной машины VHDL). Каждый сигнал может изменяться только одним процессом, что частично снимает проблему конкурентного изменения состояния. Зацикливание выявляется в рантайме (нет, мы не будем решать проблему останова).
Следует учитывать, что в VHDL не отказались ни от ветвлений, ни от циклов: в противном случае написание кода стало бы адом для программиста. Кроме того, процесс может хранить свое внутреннее состояние в локальных переменных (на них, кстати, обработчики событий навесить нельзя): это также сокращает объем кода и разгружает глобальную область видимости.
Чтобы сделать код модульным и управляемым, в VHDL поддерживаются дополнительный уровень абстракции в виде функциональных блоков (entity), все общение между которыми происходит только путем изменения входных и выходных сигналов.
В современном варианте тот же подход реализуется конечными автоматами (привет, case) в простых случаях или паттернами типа publisher/subscriber и message broker'ами — в более сложных.