От Booker
К AMX
Дата 18.03.2005 22:06:24
Рубрики Спецслужбы;

Re: Вопрос дилетанта...

>Что прям все опубликованы?

Да.

>>А что касается взлома... Ради бога пусть попробуют. :)))
>
>Кто попробует? Если вы про спецслужбы, то для открытых алгоритмов они найдут ключ за весьма короткое время. Иначе они не были бы открытыми.

Нет.

>>Алгоритм там тот же самый и он не секретен. Все дело в ключах. Они естественно будут другими.
>
>Вот уж никак не могу представить, что в рации звук будет шифроваться вживую алгоритмом, прочность которого базируется на скорости перебора ключа, т.е. для операции криптования и/или дешифрации требуются значительные по времени вычисления(для техники доступной обычному человеку разумеется).

Если ключ известен, то шифрация/дешифрация реализуются быстро. Если нет, то время подбора ключа (при достаточной длине) по известному алгоритму в настоящее время - годы. Для некоторых приложений этого достаточно.

С уважением.
От AMX
К Booker (18.03.2005 22:06:24)
Дата 18.03.2005 22:24:51

Re: Вопрос дилетанта...

>>Что прям все опубликованы?
>
>Да.

О! Вы специалист? Тогда может расскажите алгоритм генерации S-блоков для упомянутого в этой ветке ГОСТ?
И откуда вы вообще знаете что опубликовано, а что нет?
Неужели вам докладывают лично?


>>Кто попробует? Если вы про спецслужбы, то для открытых алгоритмов они найдут ключ за весьма короткое время. Иначе они не были бы открытыми.
>
>Нет.

Что нет? То что для вас и сейчас годы, для специальных машин еще 10 лет назад 7 часов.
От Booker
К AMX (18.03.2005 22:24:51)
Дата 18.03.2005 23:10:42

Re: Э-э-э.. Открытые алгоритмы это алгоритмы с открытым ключом

или Вы имеете в виду что-то сокровенное?

С уважением.
От Плюшевый сержант
К AMX (18.03.2005 22:24:51)
Дата 18.03.2005 22:38:51

Непонятно.

>О! Вы специалист? Тогда может расскажите алгоритм >генерации S-блоков для упомянутого в этой ветке ГОСТ?
Для этого есть специализированные форумы.
>И откуда вы вообще знаете что опубликовано, а что нет?
>Неужели вам докладывают лично?
По поводу упомянутого ГОСТ-а, в понедельник, думаю, начальник библиотеки гостов доложит мне, что такой гост есть. Лично.
>То что для вас и сейчас годы, для специальных машин >еще 10 лет назад 7 часов.
Думаю, это реально зависит от длины ключа. Не думаю, что для 2047-битных ключей, допустим, время это составляет 7 часов.
От AMX
К Плюшевый сержант (18.03.2005 22:38:51)
Дата 18.03.2005 22:48:48

Re: Непонятно.

>>О! Вы специалист? Тогда может расскажите алгоритм >генерации S-блоков для упомянутого в этой ветке ГОСТ?
>Для этого есть специализированные форумы.

Т.е. в вопросе вы не разбираетесь даже на уровне чайника навроде меня?

>>И откуда вы вообще знаете что опубликовано, а что нет?
>>Неужели вам докладывают лично?
>По поводу упомянутого ГОСТ-а, в понедельник, думаю, начальник библиотеки гостов доложит мне, что такой гост есть. Лично.

О какие пальцы... Специально для вас - алгоритм формирования S-блоков для древнего ГОСТ не опубликован. И толку от опубликования самого алгоритма не очень много.

>>То что для вас и сейчас годы, для специальных машин >еще 10 лет назад 7 часов.
>Думаю, это реально зависит от длины ключа. Не думаю, что для 2047-битных ключей, допустим, время это составляет 7 часов.

Реально, длина ключа для блочных алгоритмов, а разговор тут идет почему-то лишь о них, зависит от самого алгоритма и им ограничена. И вы лично получите в пользование тот, который вам посчитают возможным дать.
От Плюшевый сержант
К AMX (18.03.2005 22:48:48)
Дата 18.03.2005 23:19:39

Re: Непонятно.

>Т.е. в вопросе вы не разбираетесь даже на уровне >чайника навроде меня?
На уровне чайника, наверное, разбираюсь. Поскольку области близкие.
>О какие пальцы...
Это не пальцы. Это - нормальная работа библиотеки стандартов.
> Специально для вас - алгоритм формирования S-блоков
> для древнего ГОСТ не опубликован. И толку от
> опубликования самого алгоритма не очень много.
Очень странно. Знаете, если бы сейчас появился гост ниочем, я, возможно, поверил бы. Но в 89 году госты выпускались еще внятные. Надеюсь. Посему предположу, что упомянутые S- блоки к данному госту отношения не имеют, по каковой причине в нем и не упомянуты.
>Реально, длина ключа для блочных алгоритмов, а >разговор тут идет почему-то лишь о них, зависит от >самого алгоритма и им ограничена.
Кроме блочных, есть еще и сверточные (подкласс древовидных). И ключ может быть коэффициентами полинома.
> И вы лично получите >в пользование тот, который вам посчитают возможным >дать.
Речь идет о ключе? Это ключ мне кто-то будет давать?
От СанитарЖеня
К Плюшевый сержант (18.03.2005 23:19:39)
Дата 18.03.2005 23:35:02

Re: Непонятно.

>> Специально для вас - алгоритм формирования S-блоков
>> для древнего ГОСТ не опубликован. И толку от
>> опубликования самого алгоритма не очень много.
>Очень странно. Знаете, если бы сейчас появился гост ниочем, я, возможно, поверил бы. Но в 89 году госты выпускались еще внятные. Надеюсь. Посему предположу, что упомянутые S- блоки к данному госту отношения не имеют, по каковой причине в нем и не упомянуты.

Блоки замены - одна из существеннейших частей алгоритма ГОСТ. В тексте стандарта они не приведены, указано, что они "поставляются в установленном порядке", т.е. являются неким дополнительным элементом секретности.
Сейчас опубликованы блоки, используемые Центробанком.

>>Реально, длина ключа для блочных алгоритмов, а >разговор тут идет почему-то лишь о них, зависит от >самого алгоритма и им ограничена.
>Кроме блочных, есть еще и сверточные (подкласс древовидных). И ключ может быть коэффициентами полинома.

А Вы не путаете шифрование с кодами, исправляющими ошибки?

>> И вы лично получите >в пользование тот, который вам посчитают возможным >дать.
>Речь идет о ключе? Это ключ мне кто-то будет давать?

Именно. См. текст стандарта.
От Плюшевый сержант
К СанитарЖеня (18.03.2005 23:35:02)
Дата 18.03.2005 23:42:42

Спасибо за разъяснение

>Блоки замены - одна из существеннейших частей алгоритма ГОСТ. В тексте стандарта они не приведены, указано, что они "поставляются в установленном порядке", т.е. являются неким дополнительным элементом секретности.
Обязательно изучу.
>А Вы не путаете шифрование с кодами, исправляющими >ошибки?
Да.
От СанитарЖеня
К Плюшевый сержант (18.03.2005 23:42:42)
Дата 19.03.2005 10:33:30

Популярное изложение.

1. "Многие алгоритмы, включая DES и ГОСТ, построены по одному и тому же принципу: Процесс шифрования состоит из набора раундов-шагов, на каждом шаге выполняются следующие действия.


Входной блок делится пополам на старшую (L) и младшую (R) части.


Вычисляется значение функции шифрования от младшей части (R) и раундового ключа (k) X=f(R,k).Используемая на данном шаге функция и называется ФУНКЦИЕЙ ШИФРОВАНИЯ РАУНДА. Она может быть одна для всех раундов, или индивидуальна для каждого раунда. В последнем случае функции шифрования различных раундов одного шифра отличаются, как правило, лишь в деталях.


Формируется выходной блок, его старшая часть равна младшей части входного блока L'=R, а младшая часть это результат выполнения операции побитового ИСКЛЮЧАЮЩЕГО ИЛИ (обозначим его (+)) для старшая части входного блока и результата вычисления функции шифрования R'=L(+)f(R,k).


Tак вот, функция шифрования ГОСТа очень проста:
Младшая часть блока R и раундовый ключ складываются по модулю 2^32.


Полученное значение преобразуется по таблице замен - оно делится на 8 4-битовых групп, и каждая группа заменяется на новое значение с использованием соответствующего УЗЛА ЗАМЕН.


Полученное значение циклически сдвигается на 11 бит влево."

2. Этот класс алгоритмов шифрования именуется сетями Фейстеля.

3. Вот эти самые УЗЛЫ ЗАМЕН есть дополнительный элемент секретности.

4. Такой подход критиковался, поскольку принято (т.н. "принцип Керкгофа" )четко разделять алгоритм (и давать его для общего рассмотрения, дабы подвергнуть критике) и ключ, который засекречен и меняется регулярно. А "полусекретный" элемент меняется, но редко. Таким образом, у злоумышленника, который украдет прибор/шифровальщика он будет, а у добросовестного криптографа-исследователя, который мог бы указать на его недостатки, его не будет.

5. Таблицы (узлы) замены должны удовлетворять определенным критериям, чтобы затруднить расшифровку. Но критерии, которыми пользуются организации, наделенные правом предоставлять их - не опубликованы. Хотя вряд ли они отличаются от опубликованных для других шифров.

6. Тем не менее были утверждения, что при разработке таблиц замен в них был умышленно внесен дефект, снижающий их криптостойкость, чтобы иметь возможность расшифровывать чужие сообщения. Подтверждений этому нет, и подобные высказывания были, например, по отношению к американскому шифру DES ("Люцифер"), также быз доказательств. Однако широкому использованию ГОСТ28147-89 это отчасти препятствует.

7. Применительно к криптографии блочные шифры - в которых результат шифрования блока зависит только от данного блока, потоковые - также и от ранее переданных блоков.
От ThuW
К СанитарЖеня (19.03.2005 10:33:30)
Дата 19.03.2005 10:37:13

Хочу добавить, что уже сделана машина, вскрывающая 56бит DES, за 8 дней вроде. (-)
От Ktulu
К ThuW (19.03.2005 10:37:13)
Дата 19.03.2005 11:41:06

56bit DES и 128bit 3DES уже в прошлом. 256bit AES пусть попробуют вскрыть. (-)
От Ktulu
К Ktulu (19.03.2005 11:41:06)
Дата 20.03.2005 10:27:48

Re: 56bit DES...

Это моё личное заключение.
DES и 3DES сейчас используют только люди и организации, мягко говоря,
не совсем разбирающиеся в криптографии, или которых не волнуют
последствия расшифровки их данных.

DES был успешно достоверно вскрыт ещё в 1995 году; NSA, судя по всему, имело
возможность вскрывать DES за считанные секунды чуть ли не с начала 90-х.
http://crypto.stanford.edu/~dabo/abstracts/bioDES.html
http://www.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/

Triple DES, хотя и более криптоустойчив, сейчас также считается небезопасным.

На данный момент бельгийский 256-битный Райндол (Rijndael, он же AES) -
наиболее приемлемый вариант шифрования (по моему скромному мнению,
конечно).

--
Алексей
От AMX
К Ktulu (20.03.2005 10:27:48)
Дата 20.03.2005 12:25:11

Re: 56bit DES...

>DES и 3DES сейчас используют только люди и организации, мягко говоря,
>не совсем разбирающиеся в криптографии, или которых не волнуют
>последствия расшифровки их данных.

Постановка вопроса в корне не верная. Защищенность способа шифрования зависит не от поражающих неокрепшие умы сроков подбора, а от времени жизни ключа и необходимых ресурсов. Если я, например, использую DES в pay-tv, где ключ будет меняться каждые 2 секунды, то этот алгоритм более чем надежен. И наоборот, если вы опрометчиво поведетесь на то, что для нахождения ключа для алгоритма Х нужно 100 лет для среднего PC, и даже если это будет правда, то поставив 100 машин я найду ключик через год. И если информация к которой я получу доступ будет важна и через год, то горе вам.

А если учесть, что атаку можно производить не только методом перебора, в чем очень помогает открытость алгоритма, то ни в чем нельзя быть уверенным.
Последние новости про MD5 как раз в тему. :)
http://www.schneier.com/blog/archives/2005/03/more_hash_funct.html
От Ktulu
К AMX (20.03.2005 12:25:11)
Дата 21.03.2005 10:44:55

Re: 56bit DES...

>>DES и 3DES сейчас используют только люди и организации, мягко говоря,
>>не совсем разбирающиеся в криптографии, или которых не волнуют
>>последствия расшифровки их данных.
>
>Постановка вопроса в корне не верная. Защищенность способа шифрования зависит не от поражающих неокрепшие умы сроков подбора, а от времени жизни ключа и необходимых ресурсов.

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

> Если я, например, использую DES в pay-tv, где ключ будет меняться каждые 2 секунды, то этот алгоритм более чем надежен.
Надёжен для чего? Цель шифрования телевизионного сигнала заключается
в том, чтобы не дать смотреть этот сигнал тому, кто не знает ключ.
Но всегда можно этот сигнал записать, а потом расшифровать. Если
процедура расшифровки будет простой, т.е. занимать 1-2 секунды, то
можно будет построить устройство, которое с небольшой задержкой относительно реального времени будет выдавать этот сигнал пользователю.
А со сменой ключей - как вы собираетесь передавать новые ключи зрителям?
Или новые ключи будут содержаться в самом телевизионном сигнале?

> И наоборот, если вы опрометчиво поведетесь на то, что для нахождения ключа для алгоритма Х нужно 100 лет для среднего PC, и даже если это будет правда, то поставив 100 машин я найду ключик через год. И если информация к которой я получу доступ будет важна и через год, то горе вам.

_Я_ на это не поведусь :) В 1998 году для вскрытия DES были использованы
100 тыс. компьютеров.

>А если учесть, что атаку можно производить не только методом перебора, в чем очень помогает открытость алгоритма, то ни в чем нельзя быть уверенным.
>Последние новости про MD5 как раз в тему. :)
> http://www.schneier.com/blog/archives/2005/03/more_hash_funct.html

Про MD5 я в курсе, но это не алгоритм шифрования. В том же самом DES,
насколько мне известно, не было обнаружено явных слабостей, которые
позволяют сократить число ключей при переборе всех вариантов с 2^56
до меньшего, более приемлемого значения.

--
Алексей


От AMX
К Ktulu (21.03.2005 10:44:55)
Дата 21.03.2005 12:48:14

Re: 56bit DES...

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

И это не верно. Много чего ломают очень даже за просто так - за интерес и за свой счет, не планируя получить какую либо выгоду вообще.
От dap
К AMX (21.03.2005 12:48:14)
Дата 21.03.2005 13:02:55

Не всегда.(C) (+)

>И это не верно. Много чего ломают очень даже за просто так - за интерес и за свой счет, не планируя получить какую либо выгоду вообще.

Когда кул-хацкер Вася Пупкин взламывает защиту на компьютере ламера Ивана Сидорова – да. Но когда ломается шифр с использованием суперкомпьютера, деньги начинают играть решающую роль.
От AMX
К dap (21.03.2005 13:02:55)
Дата 21.03.2005 13:27:47

Re: Не всегда.(C)

>Но когда ломается шифр с использованием суперкомпьютера, деньги начинают играть решающую роль.

Я разве с этим спорю? Это ветка началась с такого же моего утверждения. Государство разумеется имеет в этом вопросе преимущество и обольщаться на этот счет не стоит.
От Дмитрий Козырев
К AMX (21.03.2005 12:48:14)
Дата 21.03.2005 12:55:15

Re: 56bit DES...

>>Не так, чтобы считать процедуру шифрования надёжной, стоимость расшифровки
>>должна многократно превышать (желательно, на несколько порядков) стоимость
>>самих данных.
>
>И это не верно.

Вот Вы не любите когда Вас "учат" устройству немецких танков...

>Много чего ломают очень даже за просто так - за интерес и за свой счет, не планируя получить какую либо выгоду вообще.

Под "стоимостью" здесь понимается соотношение времени и ресурсов.
Иначе говоря - будете использовать бытовой ПК - не хватит жизни (человеческой, стандарта или технологии).
Будете использовать "суперкомпьютер" - "за интерес" к нему никто не подпустит.
От AMX
К Дмитрий Козырев (21.03.2005 12:55:15)
Дата 21.03.2005 13:20:45

Re: 56bit DES...

>Вот Вы не любите когда Вас "учат" устройству немецких танков...

Намекаете на мою безграмотность в этом вопросе? :)
>Под "стоимостью" здесь понимается соотношение времени и ресурсов.
>Иначе говоря - будете использовать бытовой ПК - не хватит жизни (человеческой, стандарта или технологии).
>Будете использовать "суперкомпьютер" - "за интерес" к нему никто не подпустит.

Это и есть ошибка. РС не очень подходит для таких дел в принципе. Если вы этим делом занимались, то знаете, что скорость перебора на PC в большинстве случаев, если не удается очень хорошо оптимизировать код, ограничена доступом к памяти, т.е. не частотой процессора, а частотой шины. А если вспомнить, сколько ресурсов тратится на ОС и т.д.
В то же время создание узкоспециализированного электронного устройства стоит копейки. Для этого не надо быть гением или миллионером или иметь какой-то особый доступ к чему либо.
Суперкомпьютера не получится разумеется, но PC будет нервно курить в стороне. Поэтому оценки "скоко будет времени на PC Х Ггц" весьма лажовые на мой взгляд.
История про "неуловимого Джо".
От Дмитрий Козырев
К AMX (21.03.2005 13:20:45)
Дата 21.03.2005 13:28:09

Re: 56bit DES...

>>Вот Вы не любите когда Вас "учат" устройству немецких танков...
>
>Намекаете на мою безграмотность в этом вопросе? :)

Ну... скажем так... неосведомленность :)

>>Будете использовать "суперкомпьютер" - "за интерес" к нему никто не подпустит.
>
>Это и есть ошибка. РС не очень подходит для таких дел в принципе. Если вы этим делом занимались, то знаете, что скорость перебора на PC в большинстве случаев, если не удается очень хорошо оптимизировать код, ограничена доступом к памяти, т.е. не частотой процессора, а частотой шины. А если вспомнить, сколько ресурсов тратится на ОС и т.д.
>В то же время создание узкоспециализированного электронного устройства стоит копейки. Для этого не надо быть гением или миллионером или иметь какой-то особый доступ к чему либо.
>Суперкомпьютера не получится разумеется, но PC будет нервно курить в стороне. Поэтому оценки "скоко будет времени на PC Х Ггц" весьма лажовые на мой взгляд.

Класс "РС" приведены условно, безотносительно конкретных можделей и архитектуры. Расчет производительности идет разумеется от вычислительных мощностей процессоров. (У них есть такая характеристика - количество операций в секунду (причем как для чисел с фиксированной так и для чисел с плавающей точкой).
От AMX
К Дмитрий Козырев (21.03.2005 13:28:09)
Дата 21.03.2005 13:47:44

Re: 56bit DES...


>>Намекаете на мою безграмотность в этом вопросе? :)
>
>Ну... скажем так... неосведомленность :)

А мне кажеться, что наоборот. ;))

>Класс "РС" приведены условно, безотносительно конкретных можделей и архитектуры. Расчет производительности идет разумеется от вычислительных мощностей процессоров. (У них есть такая характеристика - количество операций в секунду (причем как для чисел с фиксированной так и для чисел с плавающей точкой).

Условно, не условно. Был такой проект по DES с использованием FPGA ака ПЛИС. Стоимость проекта 3500$(это у них я так понимаю с зарплатой, сама микросхема несколько долларов), результат 12-15 часов на полный перебор.

Xilinx у них был слабенький по нынешним временам.
От dap
К AMX (21.03.2005 13:47:44)
Дата 21.03.2005 14:42:59

АФАИК Последний рекорд 56 бит за 56 часов. :) (+)

Использовался простой перебор при помощи компьютеров добровольцев в Internet.

Однако это обычный 56-битный DES.
Для взлома 2-х ключевого TripleDES потребуется в 2^56 = 72057594037927936 больше времени.
Врядли кто-то согласится столько ждать. Даже с учетом возможного распараллеливания.
От AMX
К dap (21.03.2005 14:42:59)
Дата 21.03.2005 15:04:43

Re: АФАИК Последний...

Почитайте по линку, который я дал ниже.

"In addition, it is worth noting that with the new Xilinx FPGA10, we would be able to carry out the same attack in about 1 hour, without changing the HDL code."

"Кроме того, заметим, что используя новый Xilinx FPGA10, мы могли бы провести такую же атаку за 1 час, без изменения HDL кода."

Так что создание "супер компьютера" для криптоанализа образца середины 90-х сейчас доступно любому специалисту, умеющему программировать ПЛИС за карманные деньги.

Я отнюдь не хочу сказать, что дома можно сломать всё, я лишь хочу заметить, что подростки в интернете и время в количестве PC не показатель. Кстати "юноши со взором горящим" это тоже уже поняли и идеи, а не забацать ли нам по FPGA вместо переборки ключей на компах, сейчас не редкость.
От dap
К AMX (21.03.2005 15:04:43)
Дата 21.03.2005 16:03:59

Еще раз. Это касается 56-битного DES. TripleDES таким методом не взломать. (-)
От AMX
К dap (21.03.2005 16:03:59)
Дата 21.03.2005 16:31:13

Вы думаете я не знаю о каком DES идет речь?(+)

Был тезис: Скорость де перебора вот такая в "PC часах".
Я выдвинул контртезис: "PC часы" ничего не отражают.
Мне ответили, что де супер-компьютеры штука дорогая. Я привел пример "супер-компьютера" за весьма скромные деньги, который можно купить в магазине "ЧИП и ДИП".
И позволяет иметь любому средство для криптоанализа, которое достаточно недавно было доступно только государствам.

Что не так? :))
От dap
К AMX (21.03.2005 16:31:13)
Дата 21.03.2005 17:24:18

Кто бы с эти спорил. (+)

>Был тезис: Скорость де перебора вот такая в "PC часах".

Это просто грубая оценка. Что-то вроде "Если представить что атом размером с горошину – горошина будет размером с Землю".

>Я выдвинул контртезис: "PC часы" ничего не отражают.

Отражают сложность взлома шифра в попугаях. :)

>Мне ответили, что де супер-компьютеры штука дорогая. Я привел пример "супер-компьютера" за весьма скромные деньги, который можно купить в магазине "ЧИП и ДИП".
>И позволяет иметь любому средство для криптоанализа, которое достаточно недавно было доступно только государствам.
>Что не так? :))

Да все так. Просто в ответ на успешный взлом DES длину ключа увеличили в 2 раза и теперь взлом не доступен не только простым людям но и спецслужбам. :)
От Дмитрий Козырев
К AMX (21.03.2005 13:47:44)
Дата 21.03.2005 14:03:01

Re: 56bit DES...

>Условно, не условно. Был такой проект по DES с использованием FPGA ака ПЛИС. Стоимость проекта 3500$(это у них я так понимаю с зарплатой, сама микросхема несколько долларов), результат 12-15 часов на полный перебор.

И где можно приобрести результат их работы?
От AMX
К Дмитрий Козырев (21.03.2005 14:03:01)
Дата 21.03.2005 14:17:49

Re: 56bit DES...


>И где можно приобрести результат их работы?

Вот уж не знаю. :))
Спросите их самих http://www.dice.ucl.ac.be/crypto/publications/2002/FPL2002_crypta.pdf

Как человек работающий в сфере создания электроники и софта для торговых автоматов и платежных систем, могу сказать, что реализовать криптоалгоритмы в том же ПЛИСе это очень тривиальная задача. Их и так приходится реализовывать там для работы автоматов и пр.
А теперь представте, что я сделал такой проект, только умножил его на 1000, т.е. задействовал тысячу таких схем и разбил отрезки. ;)) И решение достаточно бюджетное для маньяка :))

А есть еще и более быстрые доступные решения. :))
От Colder
К Ktulu (21.03.2005 10:44:55)
Дата 21.03.2005 11:41:29

Передача ключей в ТВ сигнале

>А со сменой ключей - как вы собираетесь передавать новые ключи зрителям?
>Или новые ключи будут содержаться в самом телевизионном сигнале?

Собственно говоря, в САТ-ТВ именно так и происходит :), т.е. новые ключи идут в потоке сигнала. Интересная фишка в том, что при работе с оригинальными картами SAT-тюнер (точнее его CAM-модуль) как-то отслеживает изменение ключа, а вот пиратские карточки на это неспособны - по крайней мере несколько лет назад было так (с тех пор этим вопросом я не интересовался). Одно время на всевозможных сайтах САТ-ТВ ловля новых ключей была очень актуальной :).
От Ktulu
К Colder (21.03.2005 11:41:29)
Дата 21.03.2005 11:48:31

Re: Передача ключей...

>>А со сменой ключей - как вы собираетесь передавать новые ключи зрителям?
>>Или новые ключи будут содержаться в самом телевизионном сигнале?
>
>Собственно говоря, в САТ-ТВ именно так и происходит :), т.е. новые ключи идут в потоке сигнала.
В таком случае достаточно записывать весь сигнал, найти ключ для первого
блока, а дальше уже можно будет извлекать новые ключи из сигнала.
Потребуется только _одна_ операция по расшифровке методом грубой силы.

--
Алексей
От AMX
К Ktulu (21.03.2005 11:48:31)
Дата 21.03.2005 12:42:24

Re: Передача ключей...

>>Собственно говоря, в САТ-ТВ именно так и происходит :), т.е. новые ключи идут в потоке сигнала.
>В таком случае достаточно записывать весь сигнал, найти ключ для первого
>блока, а дальше уже можно будет извлекать новые ключи из сигнала.

Не считайте других идиотами. :)
Ключи вы можете получать всегда, только они тоже криптованы. Расшифровкой их занимается смарт карта и выдает ключ декодеру, который с его помощью расшифровывает поток.

>Потребуется только _одна_ операция по расшифровке методом грубой силы.

Не одна, а столько сколько раз менялся ключ и на нахождение каждого ключа у вас уйдут не секунды. Да и смотреть таким образом, т.е. офлайн, ТВ никто не будет.
От doctor64
К Ktulu (19.03.2005 11:41:06)
Дата 19.03.2005 23:11:35

Кто вам такое сказал? ;) (-)
От Ktulu
К doctor64 (19.03.2005 23:11:35)
Дата 20.03.2005 10:35:18

http://vif2ne.ru/nvk/forum/0/co/1000195.htm (-)
От doctor64
К Ktulu (20.03.2005 10:35:18)
Дата 20.03.2005 21:51:01

Тогда не пользуйтесь банкоматами.

Тут на tripleDES уже который год переходят, все никак не перейдут. EPP теоретически должен стоять на всех банкоматах - практически дай бог на половине. И так далее. О миграции на смарт-карты говорят уже лет десять, но что-то такие карты по прежнему остаются жуткой экзотикой, а техника, умеющая с ними рабоатть - встречается еще реже.
От Дмитрий Козырев
К doctor64 (20.03.2005 21:51:01)
Дата 21.03.2005 11:20:17

Это не клиент защищает свои данные, это _банк_ защищает свои данные (-)
От doctor64
К Дмитрий Козырев (21.03.2005 11:20:17)
Дата 21.03.2005 11:48:40

Нет.

Основное применение DES в банкомате - защита пин-кода клиента при передаче от банкомата в процессинг. Еще криптование используетс при смене ключей криптования иможет использоватся при МАС (message autenthication code), этакая цифровая подпись пакетов, но это уже достаточно редко. А пин-код - это практически и есть деньги клиента, оспорить транзакцию с пином клиенту очень тяжело.
PS: Хотя это уже оффтопик.
От Дмитрий Козырев
К doctor64 (21.03.2005 11:48:40)
Дата 21.03.2005 11:52:22

Да.

>Основное применение DES в банкомате - защита пин-кода клиента при передаче от банкомата в процессинг.

Клиент открывая счет в банке поручает банку распоряжаться своими средствами. За их сохранность ответсвенность несет банк.
От doctor64
К Дмитрий Козырев (21.03.2005 11:52:22)
Дата 21.03.2005 11:57:22

_Внимательно_ прочитайте договор.

>Клиент открывая счет в банке поручает банку распоряжаться своими средствами. За их сохранность ответсвенность несет банк.
Ответственность на операции с вводом пин-кода полностью лежит на клиенте. Буду рад услышать название банка, в котором это не так.
PS: на этой почве был один большой украино-польский скандал.
От dap
К doctor64 (21.03.2005 11:57:22)
Дата 21.03.2005 12:49:35

Re: _Внимательно_ прочитайте...

>>Клиент открывая счет в банке поручает банку распоряжаться своими средствами. За их сохранность ответсвенность несет банк.
>Ответственность на операции с вводом пин-кода полностью лежит на клиенте. Буду рад услышать название банка, в котором это не так.
Нет. Только за сохранение ПИН кода в тайне. Т.е. банк должен будет доказать что вы его выдали третьему лицу.
От doctor64
К dap (21.03.2005 12:49:35)
Дата 21.03.2005 12:54:18

Теоретически.

>>Ответственность на операции с вводом пин-кода полностью лежит на клиенте. Буду рад услышать название банка, в котором это не так.
>Нет. Только за сохранение ПИН кода в тайне. Т.е. банк должен будет доказать что вы его выдали третьему лицу.
Практически - это клиент будет доказывать что он никому пин не давал.
От tarasv
К doctor64 (21.03.2005 12:54:18)
Дата 21.03.2005 13:22:10

Re: Не пугайте так народ

>Практически - это клиент будет доказывать что он никому пин не давал.

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

Орфографический словарь читал - не помогает :)
От doctor64
К tarasv (21.03.2005 13:22:10)
Дата 21.03.2005 15:36:40

Re: Не пугайте...

> И чем закончисля тот украинско-польский скандал? Результат то был обратный от описанного вами типового - т.е. бабки клинтам вернули.
Вернули, хотя и не всем. Но там было две особенности - большинство пострадавших было ВИПами и банк, допустивший утечку, принимал титанические меры к тушению скандала. Почему и возвращал деньги.

> Хотя там было все и так прозрачно. Но если бы случай был единичным а не массовым, то пожалуй сработал бы ваш вариант.
Он и срабатывает. Оспорить транзакцию, подтвержденную пином, невероятно тяжело.
От dap
К doctor64 (21.03.2005 12:54:18)
Дата 21.03.2005 13:06:25

Re: Теоретически.

>>Нет. Только за сохранение ПИН кода в тайне. Т.е. банк должен будет доказать что вы его выдали третьему лицу.
>Практически - это клиент будет доказывать что он никому пин не давал.

С чего бы это? Будет иск от клиента банку по поводу исчезновения средств со счета.
Учитывая презумцию виновности, т.к. это гражданский иск, доказывать будет банк.
От doctor64
К dap (21.03.2005 13:06:25)
Дата 21.03.2005 15:39:02

Re: Теоретически.

>>>Нет. Только за сохранение ПИН кода в тайне. Т.е. банк должен будет доказать что вы его выдали третьему лицу.
>>Практически - это клиент будет доказывать что он никому пин не давал.
>
>С чего бы это? Будет иск от клиента банку по поводу исчезновения средств со счета.
И что? Банк покажет логи авторизатора, что транзакция была подтверждена вводом правильного пина. И доказывать что его не было в Куау-Лумпуре и пин он никому не давал будет клиент.

>Учитывая презумцию виновности, т.к. это гражданский иск, доказывать будет банк.
Не будет. Банк действует полностью в рамках договора.
От dap
К doctor64 (21.03.2005 15:39:02)
Дата 21.03.2005 15:58:06

Re: Теоретически.

>>С чего бы это? Будет иск от клиента банку по поводу исчезновения средств со счета.
>И что? Банк покажет логи авторизатора, что транзакция была подтверждена вводом правильного пина. И доказывать что его не было в Куау-Лумпуре и пин он никому не давал будет клиент.

Тут как раз проще всего. Если клиент докажет, что не был в Куау-Лумпуре, что как раз проще простого, то банку будет совсем несладко. Нужно будет доставать видео-запись с банкомата на которой засветился клиент либо доказывать наличие сговора клиента и того типа, который снимал деньги.
Доказательств, что клиент не разглашал ПИН-код, заведомо не может быть. Поэтому такие соображения суд в расчет не примет. Так что доказывать придется банку.

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

В договорах которые мне приходилось читать банк не несет ответственности за счет клиента с момента утраты клиентом карточки и(или) ПИН-кода до момента рассылки стоп-листов. А утрату карточки или разглашение клиентом ПИН-кода еще нужно доказать.
От doctor64
К dap (21.03.2005 15:58:06)
Дата 21.03.2005 16:30:35

Re: Теоретически.

>Тут как раз проще всего. Если клиент докажет, что не был в Куау-Лумпуре, что как раз проще простого, то банку будет совсем несладко.
Ничего подобного. Это работало с signed transactions. А вот с pi based - не покатит.

>>Не будет. Банк действует полностью в рамках договора.
>
>В договорах которые мне приходилось читать банк не несет ответственности за счет клиента с момента утраты клиентом карточки и(или) ПИН-кода до момента рассылки стоп-листов. А утрату карточки или разглашение клиентом ПИН-кода еще нужно доказать.
Цитирую договор одного крупного украинского банка.
8. Ответственность сторон.
8.3 <...> Клиент несет ответственность за операции, сопровождающиеся вводом ПИНа.
8.4 Клиент несет ответственность за все операции, сопровождающиеся авторизацией, до момента письменного заявления о блокировке средств на Картсчете и за все операции, не сопровождающиеся авторизацией, до момента постановки Карты в СТОП-ЛИСТ Платежной Системой.

Sapienti sat
От dap
К doctor64 (21.03.2005 16:30:35)
Дата 21.03.2005 17:16:51

Re: Теоретически.

>Ничего подобного. Это работало с signed transactions. А вот с pi based - не покатит.
Не вижу разницы. В любом случае этот вопрос будет решаться в суде.

>Цитирую договор одного крупного украинского банка.
>8. Ответственность сторон.
>8.3 <...> Клиент несет ответственность за операции, сопровождающиеся вводом ПИНа.
>8.4 Клиент несет ответственность за все операции, сопровождающиеся авторизацией, до момента письменного заявления о блокировке средств на Картсчете и за все операции, не сопровождающиеся авторизацией, до момента постановки Карты в СТОП-ЛИСТ Платежной Системой.

Мда. Видимо это какой-то ну очень украинский банк. В московских банкам (например в Гута-банка) такого беспредела я не наблюдал.
От doctor64
К dap (21.03.2005 17:16:51)
Дата 21.03.2005 18:45:25

Re: Теоретически.

>>Ничего подобного. Это работало с signed transactions. А вот с pi based - не покатит.
>Не вижу разницы. В любом случае этот вопрос будет решаться в суде.
Я устал. Читайте VIOR, если они у вас есть. Если нет - поверьте на слово. Послать chargeback на pin based transaction практически невозможно.

>Мда. Видимо это какой-то ну очень украинский банк. В московских банкам (например в Гута-банка) такого беспредела я не наблюдал.
Это последствия того самого скандала с утечкой пинов в Польшу. Поэтому я не устаю всем говорить - будьте осторожны с кредитками и особенно с пинами от них.
А Гута - она же того, померла?
От AMX
К dap (21.03.2005 15:58:06)
Дата 21.03.2005 16:15:19

По моему участников в этой подветке переклинило(+)

Вы забыли об одной вещи.
Чтобы найти ключ нужно знать пару: нешифрованные данные-шифрованные данные.
Как вы предполагаете нахождение пин-кода по зашифрованным данным не зная ключа? :)))
Найти ключ по известным данным, т.е. перехватить данные от получения денег самим собой? А с чего вы взяли, что ключ не изменится? :))

Мнение: алгоритм Х фигня, т.к. мало бит в ключе - ошибочно.Всё зависит от конкретной реализации для конкретной цели.

Мнение: алгоритм Х рулит, т.к. много бит в ключе - ошибочно тоже. Электроника развивается бурно, производители выкидывают на рынок дешевые решения, которые могут быть использованы для криптоанализа несмотря на то, что они для этого не предназначены изначально.

Поэтому у всех стандартизированных алгоритмов есть большой недостаток - они известны.
Вот попробуйте представить как вы будете ломать DES, у которого я изменю блоки перестановок и пусть даже я блоки выберу с изьянами.
От dap
К AMX (21.03.2005 16:15:19)
Дата 21.03.2005 17:13:07

Re: По моему...

>Вы забыли об одной вещи.
>Чтобы найти ключ нужно знать пару: нешифрованные данные-шифрованные данные.

Вы ошибаетесь. Это желательно, но не обязательно. Мы же шифруем не белый шум.

>Мнение: алгоритм Х фигня, т.к. мало бит в ключе - ошибочно.Всё зависит от конкретной реализации для конкретной цели.

Совершенно верно. Если данные к моменту дешифрования не актуальны - это хороший алгоритм. Беда в том, что нам не известны вычислительные мощности противника. Поэтому стойкость выбирают с БОЛЬШИМ запасом.

>Мнение: алгоритм Х рулит, т.к. много бит в ключе - ошибочно тоже. Электроника развивается бурно, производители выкидывают на рынок дешевые решения, которые могут быть использованы для криптоанализа несмотря на то, что они для этого не предназначены изначально.

Для этого используются шифры с размером ключа 128 бит и более. Такие шифры не ломаются прямым перебором не смотря на развитие средств выч. техники.
Так что вся надежда на криптоаналитиков.

>Поэтому у всех стандартизированных алгоритмов есть большой недостаток - они известны.
>Вот попробуйте представить как вы будете ломать DES, у которого я изменю блоки перестановок и пусть даже я блоки выберу с изьянами.

Ваше устройство будет украдено и проанализировано. Либо будет украдена проектная документация. Либо напоят одного из разработчиков или он проболтается на каком-нибудь семинаре. Вариантов море.
Ключ легко сменить, аппаратуру - гораздо сложнее.
Если устройство будет эксплуатироваться достаточно продолжительное время засекречивание алгоритма вам не поможет.
От AMX
К dap (21.03.2005 17:13:07)
Дата 21.03.2005 17:57:35

Re: По моему...

>Вы ошибаетесь. Это желательно, но не обязательно. Мы же шифруем не белый шум.

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

>Для этого используются шифры с размером ключа 128 бит и более. Такие шифры не ломаются прямым перебором не смотря на развитие средств выч. техники.

Сейчас нет. Через 50-80 лет возможно. Если возможно прищучить вас информацией, которую украдут у вас сегодня, а прочитают через 80 лет, то вы уже попали.

>Так что вся надежда на криптоаналитиков.

Которые возможно уже вас поимели, но пока помалкивают о способе, которым они это сделали как было с дифференциальным криптоанализом, о котором так долго молчали и тихо делали свое дело.
От dap
К AMX (21.03.2005 17:57:35)
Дата 21.03.2005 19:32:43

Re: По моему...

>Я не ошибаюсь. Расшифровывать шифрованные данные не имея более ничего, это уже занятие не для чайника. Достаточно простого осознания факта, что специалист такого класса не будет тырить по карманам и в данном конкретном случае этого достаточно.

Это только так кажется. В действительности в случае простого перебора наличие открытого текста не особенно облегчает жизнь. Вполне достаточно знать некоторые признаки, позволяющие отличить корректный открытый текст от случайного набора битов. Как правило, такие признаки находятся без особого труда. Это контрольные суммы, значения находящиеся в некотором фиксированном диапазоне и т.д.

>Сейчас нет. Через 50-80 лет возможно. Если возможно прищучить вас информацией, которую украдут у вас сегодня, а прочитают через 80 лет, то вы уже попали.

Боюсь даже для 128 бит будут проблемы. Причем вы упретесь не в производительность, а в необходимую для перебора энергию.
Посчитайте сами.
Примем энергию необходимую для перебора одного ключа равной энергии фотона видимого света = 36·10^-20 Дж (мне бы такой компьютер).
Тогда на полный перебор 128-битного ключа потребуется порядка 10^20 Дж.
Не многовато будет?
Для перебора 256-битного ключа энергии потребуется в 3.4*10^38 раз больше.
Спрашивается где столько взять?

>Которые возможно уже вас поимели, но пока помалкивают о способе, которым они это сделали как было с дифференциальным криптоанализом, о котором так долго молчали и тихо делали свое дело.
Какое дело? Дифференциальный криптоанализ был разработан для взлома DES однако как раз DES оказался устойчивым для этого вида криптоанализа.
Против DES хорошо работает линейный криптоанализ, однако необходимое количество пар открытый текст - шифр-текст ставит крест и на нем. Именно поэтому DES в настоящее время ломают простым перебором.
От AMX
К dap (21.03.2005 19:32:43)
Дата 21.03.2005 22:16:22

Re: По моему...

>>Я не ошибаюсь. Расшифровывать шифрованные данные не имея более ничего, это уже занятие не для чайника. Достаточно простого осознания факта, что специалист такого класса не будет тырить по карманам и в данном конкретном случае этого достаточно.
>
>Это только так кажется. В действительности в случае простого перебора наличие открытого текста не особенно облегчает жизнь. Вполне достаточно знать некоторые признаки, позволяющие отличить корректный открытый текст от случайного набора битов. Как правило, такие признаки находятся без особого труда. Это контрольные суммы, значения находящиеся в некотором фиксированном диапазоне и т.д.

Это так или иначе открытый текст. Когда результат дешифрации просто число никаких признаков у вас нет.

>>Сейчас нет. Через 50-80 лет возможно. Если возможно прищучить вас информацией, которую украдут у вас сегодня, а прочитают через 80 лет, то вы уже попали.
>
>Боюсь даже для 128 бит будут проблемы. Причем вы упретесь не в производительность, а в необходимую для перебора энергию.

Это не моя оценка. Просто такая оценка, даже если она и оптимистичная, говорит о том, что алгоритм не годится для шифрования серьезных данных.
Открытость алгоритма мера вынужденная, это лишь необходимость для его использования между несвязванными субьектами, т.е. необходимость для коммерческого применения.


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

Это как?
DES опубликован в 77-ом, дифференциальный криптоанализ в 87-ом. В том же 87 году разработчики DES заявили, что дифференциальный криптоанализ был им известен до публикования DES, поэтому он к нему и устойчив.
У вас другая, отличная от общепринятой, версия событий?
От doctor64
К AMX (21.03.2005 16:15:19)
Дата 21.03.2005 16:42:16

Re: По моему...

>Вы забыли об одной вещи.
>Чтобы найти ключ нужно знать пару: нешифрованные данные-шифрованные данные.
>Как вы предполагаете нахождение пин-кода по зашифрованным данным не зная ключа? :)))
Элементарно. Вставляем карточку с известным ПАНом и ПИНом. Перехватываем зашифрованный пин-блок. И золотой ключик у нас в кармане.

>Найти ключ по известным данным, т.е. перехватить данные от получения денег самим собой? А с чего вы взяли, что ключ не изменится? :))
Я скажу. Мало кто на украине использует сеансовые ключи. ;)

>Мнение: алгоритм Х фигня, т.к. мало бит в ключе - ошибочно.Всё зависит от конкретной реализации для конкретной цели.

>Мнение: алгоритм Х рулит, т.к. много бит в ключе - ошибочно тоже. Электроника развивается бурно, производители выкидывают на рынок дешевые решения, которые могут быть использованы для криптоанализа несмотря на то, что они для этого не предназначены изначально.
Абсолютно верно.