[SpVS 0]

Требуется провести разработку шифратора (encoder/decoder) аналогового видеосигнала, взяв за основу западный образец (или полностью самостоятельно). Оптимальным видится принцип разрезания и поворота строк.

Москва.

http://ezinearticles.com/?Video-Encryption&id=11025

[Serj78 0]

Требуется провести разработку шифратора (encoder/decoder) аналогового видеосигнала, взяв за основу западный образец (или полностью самостоятельно). Оптимальным видится принцип разрезания и поворота строк.

Москва.

http://ezinearticles.com/?Video-Encryption&id=11025

а перемешивание строк- не годится? есть готовые решения... ::)

[san822 2]

Не забудьте, что разработка любой аппаратуры шифрования требует специальной лицензии.

[SpVS 0]

а перемешивание строк- не годится? есть готовые решения... ::)

 

 

Может и годится, но в этом случае система становится намного легче для вскрытия и вариантов ключа намного меньше. Готов обсуждать.

 

Не забудьте, что разработка любой аппаратуры шифрования требует специальной лицензии.

 

 

Предположим, что разработчик провел разработку за пределами РФ, и там же ее передал заказчику. Кстати, так как это не цифровое закрытие, то для специальных служб не составит труда открыть картинку. Да и не только для служб. Надо просто, чтобы никто тупо к проводам не мог подключиться несанкционированно.

[Rst7 5]

Вам, случайно, не с видеокамер сигнал шифровать? Если да - то IP-камеры с передачей через SSH-туннель самое оно. Главное - все полностью в цифровом виде. А с криптостойкостью все впорядке, если конечно первые сертификаты на бумажке перенести.

 

Это, конечно, дорого, но заметно прогрессивнее по всем параметрам.

[SpVS 0]

Вам, случайно, не с видеокамер сигнал шифровать? Если да - то IP-камеры с передачей через SSH-туннель самое оно. Главное - все полностью в цифровом виде. А с криптостойкостью все впорядке, если конечно первые сертификаты на бумажке перенести.

 

Это, конечно, дорого, но заметно прогрессивнее по всем параметрам.

 

Я понимаю что за этим будущее, но пока это слишком дорого. И такая прогрессивность не требуется.

[san822 2]

Предположим, что разработчик провел разработку за пределами РФ, и там же ее передал заказчику. Кстати, так как это не цифровое закрытие, то для специальных служб не составит труда открыть картинку. Да и не только для служб. Надо просто, чтобы никто тупо к проводам не мог подключиться несанкционированно.

 

Ну, если это продукт не для массового рынка, то можно и без лицензии разрабатывать.

 

Если для массового рынка, то потом ещё сертификат на него получать - и там всплывут вопросы.

[SpVS 0]

Ну, если это продукт не для массового рынка, то можно и без лицензии разрабатывать.

 

Если для массового рынка, то потом ещё сертификат на него получать - и там всплывут вопросы.

 

 

Продукт не для массового рынка.

[des00 25]

может скажу бред, если задержка в 2 кадара допустима, то

 

аналог -> 656 -> AES/IDEA (любой блоковый шифр) -> 656 -> аналог.

 

+ смена ключа раз в месяц по картам :)

 

или так делать нельзя ?

[Rst7 5]

или так делать нельзя ?

 

Нельзя. Будет работать только на идеальной линии связи ;)

[cupertino 0]

Требуется провести разработку шифратора (encoder/decoder) аналогового видеосигнала, взяв за основу западный образец (или полностью самостоятельно). Оптимальным видится принцип разрезания и поворота строк.

Москва.

http://ezinearticles.com/?Video-Encryption&id=11025

Возможный способ (он не упомянут в Вашей ссылке) - сгенерировать псевдослучайный аналоговый шум (используя, например, AES в CTR mode и DAC), сложить его с передаваемым сигналом на передаче и вычесть на приеме. Компактно, дешево, криптографически надежно. К недостаткам относится снижение в два раза отношения сигнал/шум канала передачи (т.к. амплитуду исходного сигнала придется уменьшить в два раза чтобы остался динамический диапазон для добавления псевдошума).

[SpVS 0]

Недостатки серьезные, но если цена разработки и конечного устройства будет сильно отличаться от вышеупомянутого, то можно обсуждать.

 

 

 

 

Возможный способ (он не упомянут в Вашей ссылке) - сгенерировать псевдослучайный аналоговый шум (используя, например, AES в CTR mode и DAC), сложить его с передаваемым сигналом на передаче и вычесть на приеме. Компактно, дешево, криптографически надежно. К недостаткам относится снижение в два раза отношения сигнал/шум канала передачи (т.к. амплитуду исходного сигнала придется уменьшить в два раза чтобы остался динамический диапазон для добавления псевдошума).

[cupertino 0]

Недостатки серьезные, но если цена разработки и конечного устройства будет сильно отличаться от вышеупомянутого, то можно обсуждать.

Устройство будет стоить практически копейки, и разработать его нам было бы не сложно - но, учитывая наше географическое положение, Вам имеет смысл поискать более дешевых разработчиков

[blackfin 18]

Возможный способ (он не упомянут в Вашей ссылке) - сгенерировать псевдослучайный аналоговый шум (используя, например, AES в CTR mode и DAC), сложить его с передаваемым сигналом на передаче и вычесть на приеме.

IMHO, при таком способе изобажение все равно будет просматриваться на фоне шума.

Я бы предложил переставлять блоки изображения 8*8 или 4*4 в пределах кадра по случайной таблице, т.е.:

аналог -> 656 -> перемешиваем x,y координаты блоков 8*8 -> 656 -> аналог.

 

 

PS. В принципе, это практически тот же "Cut & Rotate"..

[alex_os 0]

Возможный способ (он не упомянут в Вашей ссылке) - сгенерировать псевдослучайный аналоговый шум (используя, например, AES в CTR mode и DAC), сложить его с передаваемым сигналом на передаче и вычесть на приеме. Компактно, дешево, криптографически надежно. К недостаткам относится снижение в два раза отношения сигнал/шум канала передачи (т.к. амплитуду исходного сигнала придется уменьшить в два раза чтобы остался динамический диапазон для добавления псевдошума).

Идея красивая, но много побочных эффектов будет , связанных с кривизной АЧХ-ФЧХ аналогового тракта, возможными отражениями сигнала и пр. В результате чтобы идеально убрать шум нужно будет измерять канал и делать это наверное придется на ПЧ. Вообщем не слабая система получится вроде

rake receiver :).