LINUX.ORG.RU

[параноя]swap


0

0

Насколько велика вероятность достать из сабжа ценные данные ?

Насколько обоснованным может являться его шифрование и есть ли какие либо способы его быстрого сброса ?

★★

Ответ на: комментарий от no-dashi

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

Thirty_first_Man_Down
()
Ответ на: комментарий от vasily_pupkin

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от vasily_pupkin

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

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

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

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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

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

Наоборот!

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

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

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от no-dashi

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от no-dashi

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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


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

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

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

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от no-dashi

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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


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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от no-dashi

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

Thirty_first_Man_Down
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Thirty_first_Man_Down

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

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

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от no-dashi

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

Thirty_first_Man_Down
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.