LINUX.ORG.RU

[параноя]swap


0

0

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

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

★★

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

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

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

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

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

Часто это эквивалентно: например, пакеты IP или пакеты с капсулированным HTTP/FTP/POP3

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

Щас, разбежались :-) Индивидуальные ключи - это ситуация, когда каждый из ключей предназначен строго для обмена между двумя заранее определенными пользователями, и известен только им. Схема родилась во времена, когда асимметрика не была проверена и распространена.

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

Не знаю как у вас, у нас это называется ключами зашифрования и расшифрования ^_^

Индивидуальный ключ - несколько дезориентирующие наименование ^_^ Индивидуальный он на то и индивидуальный, что есть только у одного индивида. А не у как минимум 2х ))

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

> Блочные или поточные (stream) шифры?

Любой блочны шифр "на счет раз" стандартными способами превращается в потоковый.

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

И это - под словом "продолжить" я имел в виду обсудение, а не оскорбления :-)

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

> Любой блочны шифр "на счет раз" стандартными способами превращается в потоковый.

Потоковый шифр по определению такой, который является результатом сложения по mod 2 открытого текста с шифрующей гаммой. БСШ в режиме шифрования с обратной связью - несколько не то ^_^

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

> Ради интереса - что вы понимаете под мастер-ключем?

Итак, ликбез по совецкой криптографии:

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

MKP Мастер-ключ размещения
/|\
ЗМК ЗМК ЗМК Зонный мастер-ключ
/ | |
СК СК СК Сеансовый ключ
| | | \
Д Д Д Д Данные

На рисунке показана типичная иерархия ключей защиты вычислительной сети. На верхнем уровне находится мастер-ключ размещения оборудования сети, из которого создается по одному мастер-ключу для каждого устройства, ключенного в сеть. Последние запоминаются на следующем уровне в зашифрованном виде. Каждый из этих ключей используется для шифрования и проверки целостности данных при передачи по линии связи между центрами. Они называются зонными мастер-ключами. Мастер ключ размещения никогда не передается по сети и не может быть создан автоматически с помощью генератора случайных чисел во время инициализации локального оборудования сети. Зонные мастер-ключи поддерживают взаимное соединение устройств сети, а их распространение осуществляется через курьерскую или почтовую сеть. Поскольку это трудоемкая работа, она выполняется не часто.
Не рекомендуется применять один и тот же ключ для шифрования данных в течение длительного времени; поэтому ключи данных, используемые на самом низком уровне, через опреденные интервалы времени рассылаются по сети, будучи зашифрованными собственными мастер-ключами. Эти мастер-ключи называются сеансовыми, так как их время существования не может превышать одного сеанса передачи, иногда их меняют ежедневно.
Процесс распределения сеансовых ключей включает чтение на памяти зашифрованного зонного мастер-ключа, занесение его в модуль безопасности, дешифрование с помощью мастер-ключа размещения и последующее шифрование сеансового ключа. Сеансовые ключи могут храниться под зашифрованным мастер-ключом вне модуля безопасности; поэтому функция модуля безопасности - брать зонные и сеансовые ключи в зашифрованной форму и генерировать зашифрованный сеансовый ключ для передачи данных. На приемном конце аналогичный процесс расшифровывает сеансовый ключ и зашифровывает его для хранения. Таким образом, модули безопасности обрабатывают ключи в незашифрованной форме, никогда не раскрывая зашифрованную форму ключей вне области модуля.
Модули безопасности являются существенной частью схем управления ключами, обеспечивая физически защищенную среду, в которой выполняются все криптографические операции и где хранятся ключи верхнего уровня. По мере снижения стоимости устройств памяти можно хранить все большую часть сеансовых и зонных ключей внутри модуля безопасности, поэтому даже нынешняя технология позволяет избежать повторного шифрование для их внешнего хранения. Для гарантии надежности при сбоях оборудования можно использовать несколько модулей безопасности, либо закодированные ключи можно запомнить в внешней памяти. Мастер-ключ размещения - единстенный ключ, для которого дубликат должен надежно храниться в незашифрованном виде. Модуль безопасности может выполнять ряд различных криптографических функций по командам от главной ЭВМ сети. Каждая из этих функций содержит криптографические операции, выполняемые в определенной последовательности, обеспечивая дешифрование хранимых ключей, обработку и, наконец, повторное шифрование результатов для хранения в памяти.
Если необходимо хранить в зашифрованной форме зонные мастер-ключи и сеансовые ключи на различных уровнях иерархии, то не следует использовать один и тот же мастер-ключ. Риск состоит в том, что из-за ошибочного применения модуля безопасности можно случайно получить один из ключей в незашифрованной форме. В хорошо известных схемах управления ключами фирмы IBM для целей хранения используются ключи, полученные из мастер-ключа, например, простым инвертированием определенных битов. Существуют и другие схемы, использующие, например, 8 свободных битов ключа Стандарта шифрования данных, а не битов четности. Еще один подход состоит в том, чтобы ввести ключ в некоторое сообщение, содержащее разрешение на его использование и порядковый номер, а затем зашифровать это сообщение и обеспечить его хранение.
Когда ключи зашифрованы, но не помечено, "для хранения" или "для передачи", то существует риск их неправильного использования, например при замене одного ключа другим или при подстановке старого значения ключа, который был зашифрован с помощью того же мастер-ключа. Учет этих факторов составляется важную часть полной схемы управления ключами. Далеко не все опубликованные схемы защищают от подобного рода ситуаций. Что касается конфиденциальности транспортироваки ключей верхних уровней иерархии, то здесь возникает огромный риск. Один из способов снижения риска - независимая передача отдельных частей ключа, которые также отдельно вводятся в модуль безопасности доверенными лицами. В этом случае попытка захвата ключа требует перехвата всех его составляющих. Другой способ - перенести ключ в защищенных переносимый модуль. При любом способе риск сохраняется.
В настоящее время схемы защиты с открытыми ключами используются для передачи секретных ключей, таким образом, заменяя требование обеспечение защиты на требование обеспечение целостности, которую легче обеспечить, используя многочисленные предосторожности. Более того, попытки нарушить целостность ключа должны сопровождаться активными действиями, умением преобразовывать данные на линии в реальном времени.

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

Что здесь не понятно?

Так что не все так просто с пояльником и кластером на 10 лет, нужно еще и изобретательность иметь.

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

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

По поводу предложенной атаки:

Итак, что мы имеем.

1. Открытый алгоритм.
2. Открытые таблицы замен.

При этом ОЧЕВИДНО что __длина ключа__ _намного меньше длины сообщения_.

Какой-бы алгоритм крутой не был, это существенно. Это вам не шифр Шеннона, где длина ключа = длине шифртекста. Поэтому описанная атака вполне может сработать при определенных условиях.

А то что Шифр Шеннона не имеет смысла использовать _в криптографических сетях_, это я думаю очевидно всем.

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

> Предлагаю закрыть эту тему как неконструктивную

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

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

Обеспечение абсолютного сокрытия алгоритма не является самоцелью, поскольку в случае его раскрытия придется разрабатывать новый алгоритм. Таким образом надежность шифра оценивается в предположении что алгоритм известен. Если ключ раскрыт, алгоритм считается также раскрытым, поскольку процедура дешифрована, функция D известна. Если ключ k не раскрыт, нельзя восстановить исходный текст из зашифрованного. На практике дешифровальшик (криптоаналитик), вероятно, использует значительно больше информации, чем содержится в зашифрованном тексте. Он может накапливать зашифрованные тексты в течение длительного времени и изучать их свойства. Иногда удается восстановить отдельные части исходного текста и получить информацию о свойствах избыточности, форматах и способах кодирования символов. В практической криптографии изпользуется предположение, что исходный текст всегда избыточен. В основе криптографии и криптоанализа лежит предположение, что закодированный текст получен из текста на естественном языке и простейшие приемы декодирования связаны с изучением избыточности, обусловленной, например, распределением букв алфавита в тексте. Компьютерные тексты еще более избыточны, поскольку составлены из символов кода ASCII, где буквы и числа закодированы 8-битовыми байтами. Обычно один бит в каждом байте полностью избыточен, а в длинных текстах могут появляться еще два или три избыточных бита.

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

Так что если вы гоните через криптографическую сеть /dev/urandom, ничего страшного не произойдет, а если реальные сообщения - то тут скорость взлома определяется лишь тем кому всё это нужно.

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

> При этом ОЧЕВИДНО что __длина ключа__ _намного меньше длины сообщения_.

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

> Открытые таблицы замен.

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

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

Спасибо конечно за ответ, но мне ликбез не нужен ) Просто в данной дисскусии может иметь место быть множественное толкование терминов ) См. про "индивидуальный ключ"

> которые должны удовлетворять либо условию секретности, либо целостности.

> Для открытых ключей схемы управления являются довольно простыми и должны обеспечивать только их целостность.

Ничего подобного. Дальше даже читать не буду.

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

> Предлагаю тем кто заявляет о ненужности и неконструктивности криптографии посмотреть фильм Cypher/Кодер, чтобы хоть немного отвлечься от промывания мозгов криптолоровцам.

Причем тут. В теме неконструктивный срач сомнительного содержания и не имеющий отношения к начальной теме.

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

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

Что значит в "чистом" блочном режиме?

Что у них есть "грязный" блочный режим?

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

> В теме неконструктивный срач сомнительного содержания и не имеющий отношения к начальной теме.

По видимому там имеется в виду что

Проверка целостности == подтверждение подлинности сообщения, что не так? Где я ошибся?

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

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

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

> Для открытых ключей схемы управления являются довольно простыми и должны обеспечивать только их целостность.

Согласитесь, что открытый ключ абонента A, целостность которого показана, и открытый ключ абонента Б, целостность которого показана -- две большие разницы ))

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

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

ну да, я и написал это в предыдущем посте.

Те, кто еще не догадался, это была цитата из Donald Davies, кто не знает - один из основателей интернета и пионеров компьютерной криптографии. Очевидно, что та иерархическая схема из книжки _объективно лучше_ чем одноранговая схема no-dashi где у каждой пары абонентов своя пара ключей.

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

> под целостностью вы скорее всего понимаете еще и аутентичность

проблема в том что у них слово 'integrity' значит куда больше чем слово 'целостность' которое используют наши переводчики при переводе тех. литературы

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

Вы в РФ живете? У меня сейчас кроме LOR интернета нет, по этому я не могу посмотреть ваши законы об информации и электронных документах. Там эти термины должны быть означены.

Дело в том, что "целостность" - одна из базовых услуг ЗИ. А к примеру проверка ЭЦП(signature verification) - процесс, который возможен благодаря предоставлению таких услуг. И это разные вещи.

Думаю что я не буду больше учавствовать в этом треде. Всем спасибо за беседу )

vasily_pupkin ★★★★★
()

cryptsetup спасает

топик не читал

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

> Что значит в "чистом" блочном режиме?

Я имел ввиду, что блочные шифры в своем "изначальном" блочном режиме никогда не применяются для зашифрования собственно защищаемых данных. Для зашифрования данных используются потоковые режимы этих шифров (CBC, CFB, OFB), что существенно уменьшает возможности взлома для вредителя.

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

> Очевидно, что та иерархическая схема из книжки _объективно лучше_

Это схема управления ключами. Управление ключами и стойкость ко взлому - вещи конечно связанные, но это разные сущности. Если речь идет о взломе ключа конретно взятого пользователя, абсолютно безразлично каким именно способом пользователь получил свой ключ.

P.S.: От темы не стоит уходить.

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

> Думаю что я не буду больше учавствовать в этом треде. Всем спасибо за беседу )

Согласен. Смысла нет беседовать с теми кто

1) Не знает мат. части и придумывает свои термины.
2) Придирается к словам, которые каждый может понимать по разному.
3) Необоснованно оскорбляет собеседника.
4) Считает себя старше и умнее других, абсолютно ничего не зная о участниках дискуссии.
5) Отказывается приводить ссылки на стандарты, заменяя их высказываниями вроде "я лучше знаю, так как потратил не один год на ковыряние с этим".
6) Неправильно квотит.
7) Считает себя квалифицированнее других, не имея ни одной опубликованной в рецензируемых журналах работы по криптографии.

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

> Не знает мат. части

:-) Это вы о себе любимом, не подозревавшем о том, что в одних алгоритмах некоторые параметры являются константами, и замене не подлежат?

> Отказывается приводить ссылки на стандарты

Тебе приводились названия алгоритмов

> Необоснованно оскорбляет собеседника.

"Ты идиот, true_admin", первый личный агрессивный выпад в это топике. Твой, кстати.

> Считает себя старше

С вероятностью процентов около 90

> и умнее других

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

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

Ссылки на ваши работы будут?

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

> :-) Это вы о себе любимом, не подозревавшем о том, что в одних
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
алгоритмах некоторые параметры являются константами, и замене не
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
подлежат?
^^^^^^^^


Наглейшая провокация. Думаю, что все у кого есть глаза смогут убедиться что в данном треде такого утверждения мной ВЫСКАЗАННО НЕ БЫЛО.

> Тебе приводились названия алгоритмов

Названия алгоримтов (т.н. 'GOST' и прочее) к стандартам никакого отношения не имеют.

> "Ты идиот, true_admin", первый личный агрессивный выпад в это топике. Твой, кстати.

Этот выпад связан с тем что данный юзер элементарно НЕ ЧИТАЕТ сообщения на которые отвечает. Впрочем, как и вы.

>> Считает себя старше
> С вероятностью процентов около 90

Дальше читать ваши посты даже и не буду. Явное непомерное ЧСВ и фимоз впридачу.

Итак, опять неправильный квотинг. В исходном было "Считает себя старше других". Под другими я понимал себя, и остальных участников дискуссии: id, vasily_pupkin, etc.

Даже судя по одному этому вашему ответу, ваш ментальный и реальный возраст явно меньше 35. Скорее где-то в районе 23-27. Так что ваши "процентов 90" - опять мимо.

hint: иди учи тервер. Вероятность - это число от 0 до 1. Проценты это для бухгалтеров.

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

Опыт не имеет никакого отношения к здравому смыслу и математике. Математика это не опытная наука. Да и вообще, какую ценность имеет опыт например какого-нибудь 80-летнего дебила с iq < 60. Ответ очевиден: никакого.

> Ссылки на ваши работы будут?

В Сибирском математическом журнале моих статей больше 60. Правда, моя основная специальность - математическая логика, конкретно - теория моделей. И диссер я тоже по ней защищал. Сейчас по совместительству преподаю на кафедре математики ФИТ НГУ, веду семинары по мат. логике.
В Софтлаб-НСК работаю с 1995 года.

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

> > Это вы о себе любимом, не подозревавшем о том, что в одних алгоритмах некоторые параметры являются константами, и замене не подлежат?

> Наглейшая провокация. Думаю, что все у кого есть глаза смогут убедиться что в данном треде такого утверждения мной ВЫСКАЗАННО НЕ БЫЛО.

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

В общем случае этого дела нельзя, если вы не имели ввиду какой-либо отдельно взятый алгоритм.

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

> Вероятность - это число от 0 до 1

В устной речи, когда не идет речь точном расчете, давно принято считать 0 == 0%, а 1 = 100%. Искушенный вы наш математик... Вы нам еще про матожидание и случайные величины начните рассказывать.

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

это все про реализацию ГОСТа которая была в дистрибе Альтлинукс "Утёс".

> В общем случае этого дела нельзя
Это еще почему? В стандарте это не оговорено.

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

> Альтлинукс "Утёс"
Который кстати единственный сертифицированный в РФ гостехкомисией.
(приносили купленную коробочную версию на работу поиграться)

Почему, по вашему, они нарушают сформулированные вами требования на "криптографические сети"?

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

Thirty_first_Man_Down
()

swap не нужен.

ЗЫ: трид не читал.

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

> это все про реализацию ГОСТа которая была в дистрибе Альтлинукс "Утёс".

Согласен, в этом случае это делать можно, и то что это делать пришлось, на самом деле ошибка разработчиков (хотя ноги у этой проблемы растут из ограничений cryptoloop).

> > В общем случае этого дела нельзя

> Это еще почему? В стандарте это не оговорено.

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

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

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

Потмоу что я делал ее ради спортивного интереса, и основной задачей было изучить cryptoloop. Кроме того, я очень не люблю "сертифицированные программные продукты".

> Который кстати единственный сертифицированный в РФ гостехкомисией.

Там есть куча разных сертификаций, и криптографическая подсистема "Утеса", насколько я помню, не сертифицировалась как собственно криптографический продукт. Он сертифицировался только на НСД, контроль доступа и прочее. Тот уровень, на которые Альты получили сертификат, не включал требований на криптографию.

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

> Потмоу что я делал ее ради спортивного интереса

Ну и вдобавок ко всему, cryptoloop является deprecated-кодом, поэтому то что было заточено сугубо под cryptoloop, на самом деле было нежизнеспособно.

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

> Я уже отмечал, что если у алгоритма явно написано "эта таблица/констатнта/синхропосылка может быть выбрана пользователем" - это делать можно, если этого нельзя сделать в конкретной реализации (таблица вкомпилирована) - это ограничение (не ошибка!) реализации. Если это не сказано - увы, значит делать этого нельзя.

Так давайте всё же проясним ситуацию.
В начале треда я написал что "элементарное не могу проверить таблицы замен в DES-е потому что у меня не хватает квалификации". _Вы написали что можете._ Дальше "срач" про образование дипломы и етц пошел из-за этой фразы.

ссылка: http://williamstallings.com/Extras/Security-Notes/lectures/blockA.html


DES Design Principles
although the standard for DES is public, the design criteria used are classified and have yet to be released
some information is known, and more has been deduced
L P Brown, "A Proposed Design for an Extended DES", in Computer Security in the Age of Information, W. J. Caelli (ed), North-Holland, pp 9-22, 1989

L P Brown, J R Seberry, "On the Design of Permutation Boxes in DES Type Cryptosystems", in Advances in Cryptology - Eurocrypt '89, Lecture Notes in Computer Science, vol 434, pp 696-705, J.J. Quisquater, J. Vanderwalle (eds), Springer-Verlag, Berlin, 1990.

L P Brown and J R Seberry, "Key Scheduling in DES Type Cryptosystems," in Advances in Cryptology - Auscrypt '90, Lecture Notes in Computer Science, vol 453, pp 221-228, J. Seberry, J. Pieprzyk (eds), Springer-Verlag, Berlin, 1990.
will briefly overview the basic results, for more detailed analyses see the above papers
------------------------
DES Permutation Tables
-----------------------
there are 5 Permutations used in DES:
IP and IP^(-1) , P, E, PC1, PC2

their design criteria are _______CLASSIFIED SECRET________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



it has been noted that IP and IP^(-1) and PC1 serve no cryptological function when DES is used in ECB or CBC modes, since searches may be done in the space generated after they have been applied
E, P, and PC2 combined with the S-Boxes must supply the required dependence of the output bits on the input bits and key bits (avalanche and completeness effects)


Конечно, если у вас есть ДОПУСК к американской "CLASSIFIED" то вы на голову выше меня.

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

> В начале треда я написал что "элементарное не могу проверить таблицы замен в DES-е потому что у меня не хватает квалификации". _Вы написали что можете.

Я говорил, что могу проверить реализацию алгоритма, но не его криптостойкость :-)

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

> Я говорил, что могу проверить реализацию алгоритма, но не его криптостойкость

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

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

> Я говорил, что могу проверить реализацию алгоритма, но не его криптостойкость :-)

Ну уж простите, проверить код по бумажке-описанию любой дурак может.

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

Да даже и про реализацию. В ядре первоначально крипто было реализовано далекими от этого людьми. Так вот, я несколько раз видел опечатки в опубликованных стандартах даже в таблицах замен, "подумаешь отличаются от оригинальных на одну цифру, и что?" %) Но конечно это уже вопиющие случаи.

>> Вы можете проверить реализацию какого-нибудь Twofish-а в ядре?

>Могу. Образование и подготовка позволяют. И любой другой может.

>> Или исправить, при этом не сделав так чтобы ваша реализация не ломалась за несколько часов машинного времени?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
как раз этой фразой я хотел сказать что криптостойкость определяется в том числе "реализацией", "версией", "модификацией", как вам угодно таблиц замен. Вообще я думал мы тут обсуждаем не чистокодописание, а реальные применения криптографии в жизни на достаточно серьезном уровне.

> ЛЮБЫЕ ДВЕ корректные реализации одного алгоритма при одних и тех же исходных данных (plaintext + key) генерируют один и тот же
<skipped>


По поводу того, кто там говорил что "криптография это не магия" и про то что все подводные камни известны обществу. Буквально на эту тему пример (думаю он достаточно современный для крипто) (цитата из вики): "Differential cryptanalysis was rediscovered in the late 1980s by Eli Biham and Adi Shamir; it was known earlier to both IBM and the NSA and kept secret. To break the full 16 rounds, differential cryptanalysis requires 247 chosen plaintexts."
Кто знает сколько еще таких тузов в рукаве у "Большого Брата"

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

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

По поводу непонимания - согласен. Но это чисто "внешняя" проверка, в истории не так уж много случаев когда такие "грубые" трюки злоумышленников срабатывают. ИМХО криптоанализ работает намного тонкими методами, начиная с нацисткой "Энигмы" и заканчивая современным шифром Skipjack который NSA со своим Clipper chip-ом пыталась пихать во все устройства в 90-е годы.

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

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

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

> Речь же шла про ъ-крипто которое вы (или кто там, топикстартер) собирается противопоставить правительству/спецслужбам/транс-национальным корпорациям

Эммм... Мы опять спускаемся к тому же с чего начали. Спецификации алгоритмы содержат (или как минимум должны содержать) открытые критерии определения "слабости" ключевой информации. Если такие критерии не опубликованы, алгоритм рекомендуется отправить в печь (в топку, как здесь говорят).

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

Вообще, говоря "реализация" я имел ввиду код - и это куда как более важно, в действительности. Толку в использовании "самого-неломаего-шифра-в-мире-в-нашем-продукте", если в процессе зашифрования документа "продукт" создает копию файла, которую позже удаляет обычным unlink? И толку в в самых-что-ни-на-есть-наворочанных механизмах защиты, если ключ в открытом виде лежит в энергонезависимой памяти устройства, пусть и недоступный для запроса к устройству по внешней шине? На чем лажанулся автор последней версии шифрующего данные вируса, в курсе? В крайнем случае, всегда есть плоскогупцы, иглы и паяльник.

Открытые продукты позволяют вычистить такие промахи, закрытые - нет. Какие гарантии, что в ППЗУ "аппаратно шифрующего" винта не лежит заксореный ключ, или что он не пишет этот ключ в области, обычно предназначенные для ремапа сбойных секторов? Об этом изначально и шла речь. И в быту, IMHO, гораздо опасней такие практические "лючки" чем теоретические слабые таблицы замен, которые при знании определенных плейнтекстов и шифртекстов к ним позволяют восстановить ключ не за 1000 лет, а всего за 100? Ну и что же, что в сферическом виндовсе слабая функция хэширования пароля - мы скринсейвер на cmd.exe заменим, влепим трояна и вперед и с песнями...

Слабости допущенные программистами гораздо более опасны, чем теоретические "слабости" в алгоритме.

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

> ИМХО криптоанализ работает намного тонкими методами

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

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

> Слабости допущенные программистами гораздо более опасны, чем теоретические "слабости" в алгоритме.

Social engineering в свою очередь гораздо более опасна чем баги в программах, так что, теперь всем наплевать на теорию?

Тут должен быть разумный баланс.

В наше время "программист" который допускает такие баги никогда не поднимется выше кодера в приличных конторах, т.е. до критических мест его просто не допустят.

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

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

Я и написал в начале что против пром. шпионажа всё это не поможет.

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


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

Пример с бухгалтерией и налоговой некорректен. Слишком несопоставима ценность информации и стоимость взлома.

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

Кстати, есть оборудование, которое может восстановить инфу с диска стертую хоть шрёдером, используя остаточные магнитные явления (или как там это называется, не помню, я не физик). Так вот, это тоже входит в методы "чистого" криптоанализа.

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