[параноя]swap

и вообще поймите же наконец что даже у фразы 'ключевой элемент' есть как минимум ДВА толкования: элемент ключа и НЕОТЪЕМЛИМЫЙ ЭЛЕМЕНТ АЛГОРИТМА

> Простите что вмешиваюсь, а что собственно за ISO 9160?
Это стандарт на блочные шифры с обратной связью.
Ничего он не запрещает, но и ничего не оговаривает.

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

Такой прикол походу только у госта. у обсуждаемых ни у 46, ни у 197 такого нет. Конечно если быть точнее поменять можно что угодно, но если в 46 это упоминается и явно не рекомендуется, то в 197 об этом и речи не идет.

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

> А что здесь собственно некорректно?

Все корректо, просто это не имеет НИКАКОГО отношения к тому что мы обсуждаем. А именно, ТАБЛИЦЫ ЗАМЕН.

Внимание, вопрос знатокам:
1) ключ это не таблица замены;
2) таблица замены это не данные.
3) в стандарте по шифру ГОСТ какой-то там номер (заметьте по 1 ШИФРУ а не ПО ВСЕМ блочным, причем который придумали у нас) ничего про таблицы не сказано (я еще не видел прямую ссылку на стандарт, поэтому "со слов" гугля).

Какой из этого можно сделать вывод? Либо просто непонимание (тогда зачем наезжать на собеседника), либо троллинг, со стороны no-dashi.

К чему он вообще был упомянут?

> К чему он вообще был упомянут?

Там было сказано (насколько я помню с универа) что таблица замен это часть реализации шифра (именно было сказано что-то вроде cryptoalgorithm implementation, не могу точно сказать, потому что под рукой нет, поэтому я и прошу приводить четкие ссылки, а не вырывать фразы из контекста вроде той же 'ключевой информации'), а не его алгоритма.

Перечитал тред. Куча вылитых помоев из-за опасного высказывания по поводу того, что изменение таблицы подстановки => изменение шифра(?).

В некотором количестве случаев утверждение верно, в некотором нет. Зато фекалий сколько (=

Да вот в том-то и дело. Я написал изменение "реализации алгоритм" и помои полились на меня то что я недоучка.

А я всего лишь хотел сказать что нет гарантии что в оперсорсных шифровалках сделано всё по умного проведены миллионы тестов, как в той статье про ГОСТ ссылку на кот. я приводил. Так же нет гарантии что это правильно реализовали в IBM. Но, так как они и есть авторы DES-а то у меня к ним доверия больше, чем к абстактному криптографу из opensource community.

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

вот-вот я обсуждаю вообще все абстрактные блочные шифры, а no-dashi начинает тыкать мне русским шифром 'ГОСТ', какая разница как он называется, хоть 'МОРГ', это не повод сводить к нему все шифры.

no-dashi сказал:
> таблицы замен и ключа (и то, и другое ГЕНЕРИРУЕТСЯ ПОЛЬЗОВАТЕЛЕМ)

> Т.к. в стандартах есть эти самые 1000 раз проверенны таблицы - все хорошо и все счастливы.

А вот no-dashi почему-то утверждает что это только забота пользователя.

> В случае с программной реализацией это сделать (для конечного пользователя-параноика) проще.

А вдруг злые дядьки из 'Дворца Загадок' решили сделать мне пользователю-параноику большую лажу - опубликовали галимые таблицы, которые все стандартные тесты проходят, а на самом деле шифр можно раскрыть одним им известной атакой. Тогда какая разница, откуда ждать удара - от производителя устройсва или от правительства?

> А вдруг злые дядьки из 'Дворца Загадок' решили сделать мне пользователю-параноику большую лажу - опубликовали галимые таблицы, которые все стандартные тесты проходят, а на самом деле шифр можно раскрыть одним им известной атакой.

Где то в 50х годах был озвучен тезис о том, что криптография должна быть открытой. Это было сделано примерно из вот таких соображений :)

БСШ - это не генератор случайных чисел. Там нет стандартных тестов. Есть известные атаки. БСШ проверяется на стойкость к ним. Все. Всегда существует вероятность того, что злые дядьки знают мегаспособ взлома "одной атакой". Примерно такой же, как встретить на улице инопланетянина.

> Тогда какая разница, откуда ждать удара - от производителя устройсва или от правительства?

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

Если разработчик БСШ допустил ошибку в алгоритме, то ее вероятнее всего найдут. Т.к. миллионы глаз будут буровить этот несчастный алгоритм вдоль и поперек.

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

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

> Примерно такой же, как встретить на улице инопланетянина.
Я считаю что пользователи которые используют только шифр "ГОСТ" - 'инопланетяне'.

> БСШ - это не генератор случайных чисел. Там нет стандартных тестов. Есть известные атаки. БСШ проверяется на стойкость к ним.

Можно спроектировать это так, как в варианте 'запасной ключ', backdoor, так чтобы она вскрывалась 1 _заранее_ придуманной им атакой и сгенерировать табличку под эту атаку. На все остальные атаки это не повлияет.

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

Наоборот!

Сначала обсуждалось хардварное шифрование, я сказал что использую только его + опенсорсное шифрование sensitive data файлов, таких как аська/почта, так как элементарно на моем лаптопе нет кодов запуска ядерных ракет и прочей инфы которой так много у пользотателей ЛОРа, шифрующих свои SWAP-ы.

Меня начали упрекать что производители врут, пихают вместо шифров XOR-ы по гамме.

Я сказал что мне все равно, имею я доступ к исходникам FIRMWARE винта или нет, я предпочитаю верить фирмам со столетней репутацией. То есть мне пофиг на 'security through obscurity'. Открытый, закрытый, какая, разница.

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

1. Железо обычно лучше отлаживают.
2. Оно лучше верифицируется.

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

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

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

И с чем ты ковырялся, с вендой, с проприетарными поделиями?

В линуксе (то что называет loopback device crypto или как там, я же говорю давно не юзал, не помню) мне потребовалось __перекомпиляция ядра__/__модулей__ чтобы элементарно изменить таблицы замен.

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

Так что на свой стаж ссылаться не надо, я тебе не школьник/студент.

> Можно спроектировать это так, как в варианте 'запасной ключ', backdoor, так чтобы она вскрывалась 1 _заранее_ придуманной им атакой и сгенерировать табличку под эту атаку. На все остальные атаки это не повлияет.

Спроектровать можно что угодно. Только пользуются тем, где такого нет. Криптография это не магия ^_^

> Меня начали упрекать что производители врут, пихают вместо шифров XOR-ы по гамме.

Ведь это имело место быть.

> Я сказал что мне все равно > я предпочитаю верить фирмам со столетней репутацией. > мне пофиг на 'security through obscurity'

Я немного не понял. Если вы не относитесь к числу параноиков шифрующих свой свап, какой резон был вести дисскусию? (=

> Я написал изменение "реализации алгоритм"

В том то и дело, что для DES/AES*Fish и прочих стандартная таблица замен является неотъемлимым станартизированным элементом шифра. И какое-либо ее изменение автоматически превращает измененную реализацию в "что-то похожее, но не то", она не ДАННЫЕ для алгоритм, она его составной элемент. "на первом цикле "A" заменяется на "B", а на втором "А" заменяется на "Е"".

Поэтому все рассужения про "конкретно взятую реализацию" просто мыло и чушь. Отличаться "реализации" они могут только в том, насколько надежно прячется ключ, и насколько хорошо зачищается изначальный текст - что в открытых и программных реализациях проверяется на порядки легче.

В отличие от ГОСТа, в котором эта таблица всего лишь данные, как и сбоственно ключ (256 бит).

Чего чего? (=

Криптографическая сеть - это что такое? (=

вообще что гугль и яндекс находит по фразе 'криптографическая сеть' это ссылка на описание какой-то квантого-криптографической сети.

Не знаю где такое преподают, но когда я учился на матфаке такого словосочетания просто __не было__ в программе курсов/на лекциях/в учебниках/етц.

> насколько надежно прячется ключ

Если реализация прячет ключ - это совсем беда (=

> В том то и дело, что для DES/AES*Fish и прочих стандартная таблица замен является неотъемлимым станартизированным элементом шифра.

Так что, по-твоему, ты как развертыватель криптографической сети, нарушась писанные черным по белому стандарты?

Если бы бог был бы разработчиков этих криптостандартов, то ты бы уже горел в аду.

> В линуксе (то что называет loopback device crypto или как там, я же говорю давно не юзал, не помню) мне потребовалось __перекомпиляция ядра__/__модулей__ чтобы элементарно изменить таблицы замен.

Исправив таблицы замен, ты создал ДРУГИЕ шифры. Которые генерируют другой шифртекст и по другим правилам. Когда я занимался реализацией госта из спортивного интереса, я навесил на cryptoloop еще один ioctl, который позволял сбросить в драйвер таблицу замен.

Это я к тому, что если в алгоритме явно сказано "этот элемент обязан иметь указанное значение" - это значение зашивается константой. Ибо так надо. А если значение элемента не указано, то оно должно сбрасываться в алгоритм и быть динамическим (ключ, таблица замен).

> Спроектровать можно что угодно. Только пользуются тем, где такого нет. Криптография это не магия ^_^

Да ну, а вот автор книжки 'The Puzzle Palace' приводил факты что таким образом ОНИ (анб) сумели все-же кого-то нагреть.

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

> Я немного не понял. Если вы не относитесь к числу параноиков шифрующих свой свап, какой резон был вести дисскусию? (=
Я же сказал что шифрую все подряд, не только свап! А выделять отдельно свап - это бред. Может у меня его вообще нет.

> Исправив таблицы замен, ты создал ДРУГИЕ шифры. Которые генерируют другой шифртекст и по другим правилам. Когда я занимался реализацией госта из спортивного интереса, я навесил на cryptoloop еще один ioctl, который позволял сбросить в драйвер таблицу замен.

> если в алгоритме явно сказано "этот элемент обязан иметь указанное значение"

А если не указано, значит все пучком (=

> Так что, по-твоему, ты как развертыватель криптографической сети, нарушась писанные черным по белому стандарты?

Сначала я хотел тут написать мат, но потом успокоился.

При развертывании криптографической сети для алгоритма ГОСТ, я, как представитель той самой уполномоченной организации, генерирую все необходимые данные - единую таблицу замен и индивидуальный ключ для каждой пары пользователей, потому что в стандарте сказано, что я обязан ее (таблицу) сгенерировать.

Если бы я развертывал сеть под AES или Twofish, то генерировал бы только ключи, поскольку таблица замен определена в стандарте, и ее менять по стандарту запрещено.

> Если реализация прячет ключ - это совсем беда (=

Спрятать - это при инициализации контекста сделать copy_from_user, объявить страницу несвапируемой и ни через один ioctl/read/recv не отдавать ключ обратно :-)

а не кажется что многовато ключей ты уже нагенерировал?

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

> Да ну, а вот автор книжки 'The Puzzle Palace' приводил факты что таким образом ОНИ (анб) сумели все-же кого-то нагреть.

Использовалась одна известная половина ключа. Это уже ближе к административным мерам.

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

Ну как зачем. Вот купил Хакер Петя себе винчестер с Аппаратным Шифрованием. И думает что там AES и вообще весь B-Suite. А там xor. И надо об этом сказать, что бы другие товарищи были осторожнее со своими верованиями, ибо ничто так не опасно, как иллюзия наличия защиты.

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

У вас нет, а у ID есть. Если нет аппаратного шифрования, то можно свап и не шифровать, т.к. это вроде как замедлит работу. Так что вопрос имеет адекватную составляющую. (=

> Криптографическая сеть - это что такое?

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

> Если инфа одна и та же шифруется разными ключами, это _сильно облегчает взлом_.

С чего вы так решили?

итак, имеется в наличие

у законного юзера 1:

1 шт. plaintext, 1 шт. ключ, 1 шт ciphertext(полученный из plaintext и key применением тру-алгоритма 'ГОСТ')


у законного юзера 2:

1 шт. plaintext (тот же самый, 1 шт. ключ(другой), 1 шт ciphertext(полученный из plaintext и key применением тру-алгоритма 'ГОСТ') (тоже другой)

у крутого-man-in-the-middle-хакира:

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

Ничего не напоминает?

> Если инфа одна и та же шифруется разными ключами, это _сильно облегчает взлом_.

Мля. Не играй в тупого. Информация шифруется в момент отправки от юзера А к юзеру Б. Просто генерируются индивидуальные ключи, например, для четырех пользователей (А,Б,В,Г) генерируется шесть ключей - для обмена А-Б, А-В, А-Г, Б-В, Б-Г, В-Г.

> > Если инфа одна и та же шифруется разными ключами, это _сильно облегчает взлом_.

> С чего вы так решили?

Это не он так решил, это другие (титулованные) дядьки так написали.

> Не играй в тупого.
Аналогично.

-- про public-key мы тут ничего не обсуждали, только про блочные СИММЕТРИЧНЫЕ ШИФРЫ --

> Это не он так решил, это другие (титулованные) дядьки так написали.
4.2
Я думаю всем ясен уровень собеседника?

И что дальше?

> Если инфа одна и та же шифруется разными ключами, это _сильно облегчает взлом_

1. Не для всех алгоритмов. 2. Не для всех данных. 3. не сильно. Гугл вам в помощь.

дальше тупой Brute-Force с эвристикой (алгоритм шифрования известен, таблицы тоже известны (ну если они стандартные и везде одинаковые)).

> тут ничего не обсуждали, только про блочные СИММЕТРИЧНЫЕ ШИФРЫ

Юноша, индивидуальные ключи != сеансовые ключи

> 1. Не для всех алгоритмов. 2. Не для всех данных. 3. не сильно.

Да даже если для каких-то и не сильно. Кому-то и этого хватит, вкупе с другими методами.

> Юноша, индивидуальные ключи != сеансовые ключи

Все с тобой ясно.
Дальше просто продолжать разговор не имеет смысла.

> Кому-то и этого хватит, вкупе с другими методами.

С паяльником в попу и кластером из креев, занятых расчетами на 10 лет, да.

> тут ничего не обсуждали, только про блочные СИММЕТРИЧНЫЕ ШИФРЫ

Юноша, индивидуальные ключи != сеансовые ключи

НЕ НАДО ТАК ДЕШЕВО ПОДМЕНЯТЬ ЦИТАТЫ, МАЛЬЧИК, В ИСХОДНОЙ БЫЛО НАПИСАНО:


-- про public-key мы тут ничего не обсуждали, только про блочные СИММЕТРИЧНЫЕ ШИФРЫ --

"сеансовые ключи" имеют смысл если есть pki вроде RSA.

> 1. Не для всех алгоритмов. 2. Не для всех данных. 3. не сильно. Гугл вам в помощь.

Ближе к истине будет - никак.

> дальше тупой Brute-Force с эвристикой

Чушь. В данной ситуации это бесполезно - cущественные проблемы начнутся, если станут известны несколько фрагментов исходного текста и соответствующего им шифртекста.

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

А про вырожденные ключи (проблема не только DES, но он больше всего ей подвержен), недоучка, ты хоть что-нибудь слышал?

> Brute-Force с эвристикой

Не совсем понимаю к чему тут эвристика. Brute-Force == атака грубой силой. Это та самая величина, которой определяется базовая стойкость КА. Думаю дальше понятно,

Причем вырожденные ключи к тому что было обсуждено?

Ну-ка, поднимем историю разговора?

no-dashi: Информация шифруется в момент отправки от юзера А к юзеру Б. Просто генерируются индивидуальные ключи, например, для четырех пользователей (А,Б,В,Г) генерируется шесть ключей - для обмена А-Б, А-В, А-Г, Б-В, Б-Г, В-Г.

Thirty_first_Man_Down -- про public-key мы тут ничего не обсуждали, только про блочные СИММЕТРИЧНЫЕ ШИФРЫ --

no-dashi: Юноша, индивидуальные ключи != сеансовые ключи

Так кто тут спутал индивидуальные ключи некоторого симметричного алгоритма и pki?

Я еще раз подчеркиваю - знание того, что одна и та же информация шифруется разными ключами и знание шифртекста по результатам применения этих ключей не облегчает жизнь злоумышленнику, ЕСЛИ ОН НЕ ЗНАЕТ СТРУКТУРЫ ИСХОДОГО ТЕКСТА.

Не структуры, а открытого шифр текста.

Индивидуальный ключ == личный ключ == private key? (=

Сколько левых терминов ^_^ Наверное все издержки переводов.

Не следует путать сеансовые ключи с мастер-ключами. В некоторых случаях это одно и тоже, в некоторых нет. Схем управления ключами придумано дофига, так что обобщать отдельные случаи на всю область не следует.