Скрытие информации. Скрытие информации криптографическим методом

Правило Скрытия Информации можно сформулировать следующим образом:

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

Применение этого правила означает, что каждый модуль известен всем остальным (то есть разработчикам других модулей) через некоторое официальное описание, или так называемые общедоступные (public) свойства.

Конечно, таким описанием может быть весь текст модуля (текст программы, текст проекта): он и обеспечивает правильное представление о модуле, поскольку это и есть модуль! Но правило Скрытия Информации устанавливает, что в общем случае это не обязательно: описание должно включать лишь некоторые из свойств модуля. Остальные свойства должны оставаться не общедоступными, или закрытыми (секретные) (secret) . Вместо терминов - общедоступные и закрытые свойства - используются также термины: экспортируемые и частные (скрытые) (private) свойства. Общедоступные свойства модуля известны также как интерфейс (interface) модуля (не следует путать с пользовательским интерфейсом системы программирования).

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

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

Рис. 3.10. Модуль в условиях скрытия информации

В качестве характерного примера рассмотрим процедуру поиска по ключу атрибутов, хранящихся в таблице, такой как картотека личного состава или таблица идентификаторов компилятора. Эта процедура существенно зависит от способа представления таблицы - последовательный массив или файл, хэш-таблица, двоичное или индексное (B-Tree) дерево и т.д. Скрытие информации означает, что выбранный способ реализации таблицы не влияет на использование такой процедуры. Модули-клиенты не должны страдать от каких-либо изменений в реализации программы.

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



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

Однако эта рекомендация является нечеткой, так как не дано определение спецификации (specification) и реализации (implementation). Действительно, можно поддаться искушению, изменив определение на прямо противоположное, и утверждать, что спецификация состоит из общедоступных свойств модуля, а реализация - из его скрытых свойств! ОО-подход обеспечит намного более точные рекомендации на основе теории абстрактных типов данных.(См. лекцию 6, в частности "Абстрактные типы данных и скрытие информации".)

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

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

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

Одной из причин вышеупомянутого недопонимания является сам термин "скрытие информации" ("information hiding"), который наводит на мысль о защите физического характера. В этом смысле предпочтительным, по-видимому, мог бы явиться термин "инкапсуляция" ("encapsulation"), иногда используемый в качестве синонима скрытию информации, однако в нашем обсуждении будет по-прежнему использоваться общий термин "скрытие информации".

Из этого обсуждения следует, что ключом к скрытию информации являются не решения по организации доступа к исходному тексту модуля в рамках управления проектом или маркетинговой политики, а строгие языковые правила, определяющие, какие права на доступ к модулю следуют из свойств его источника. В следующей лекции показано, что первые шаги в этом направлении реализованы в таких "языках с инкапсуляцией" как Ada и Modula-2. Объектно-ориентированная технология программирования приведет к более полному решению проблемы.

Лет восемь назад (был на втором курсе) мой научный руководитель предложил мне в качестве темы курсовой исследование и реализацию стеганографических методов. Тема тогда была намного более новая, чем сейчас. Как-то вспомнилось - решил написать заметку. Итак... Стеганография - это наука, изучающая способы скрытой передачи информации путем скрытия самого факта передачи. Наука - абсолютно не новая по своей идее, но с изобретением цифровых способов реализации алгоритмов, применяемых в ней, ее развитие вышло на существенно новый уровень. Ввиду серьезности возможных последствий результатов применения стеганографических методов в реальной жизни и наличия людей, жаждущих острых ощущений, сразу хочу написать disclaimer:) Автор не несет никакой ответственности за возможное (злонамеренное) использование каких бы то ни было методов стеганографии и их реализаций третьими лицами и рассматривает данный материал исключительно с образовательной и исследовательской точек зрения. Вся информация получена из открытых источников и собственных наблюдений и опытов. Как мы выяснили, стеганография преследует своей целью обеспечение сокрытия и защиты информации от несанкционированного доступа. Похожие цели ставит перед собой и криптография. Существенным отличием является то, что задача криптографии - предотвратить несанкционированный доступ к информации путем двустороннего применения математических алгоритмов к данным (шифрование). Основная задача стеганографии - именно скрытие факта наличия конфиденциальной информации. Сложность алгоритмов может быть разной и влияет (в случае конечного множества принимаемых значений из области определения) на время поиска решения, которое в идеале сводится к бесконечному. На практике, естественно, применяются ключи шифрования конечной длины, что подразумевает наличие конечного множества возможных вариантов для перебора или подбора значений... Это очень обширная тема. Целью статьи не является подробное освещение особенностей алгоритмов шифрования. Скажу только (в качестве примера), что на рубеже XXI века по не до конца подтвержденным данным китайские математики смогли доказать возможность уменьшения вариантов для перебора в алгоритме SHA-1 (на основе получения хэша) с примерно 80 порядка до 63, т.е. на 17(!) порядков сразу. SHA-1 считается очень стойким алгоритмом и применяется, опять-таки - по неподтвержденным данным, правительством США как один из основных алгоритмов шифрования... (информация из открытых источников) Также, на проходившей в конце апреля-начале мая конференции Eurocrypt 2009, была продемонстрирована серьезная системная уязвимость алгоритма SHA-1, способная скомпрометировать использующие его приложения. Незадолго до опубликования отчета на Eurocrypt Национальный институт стандартов США (NIST) распорядился к 2010 году прекратить использование SHA-1 в правительственных учреждениях. Не далее, как в ноябре 2008 года, Stéphane Manuel опубликовал наличие уязвимости, снижающей сложность до 57 порядков. А уже на Eurocrypt 2009 была продемонстрирована уязвимость с возможностью уменьшения количества вариантов "всего" до 52 порядков!. Для современных суперкомпьютеров это действительно практически пустяки, чтобы считать такой алгоритм надежным... Хотя еще совсем недавно он считался крайне надежным. Однако, я отвлекся. Вернемся к возможности применения стеганографии. Каким же образом можно скрыть сам факт наличия информации? Необходимо поместить ее в такой контейнер, который бы не вызвал подозрения... Однако любое размещение _дополнительной_ информации в какой-либо контейнер влечет за собой модификацию контейнера, что уже само по себе подозрительно. Однако, и данная задача нашла решение:) На сегодняшний день наиболее интересным вариантом, с точки зрения скрытия информации, является использование медиа-файлов как контейнеров. Возникает вопрос: а как это работает? Для ответа необходимо разобраться со структурой медиа-форматов. Основные - это графика, звук и видео... Начнем с графики. Известно, что изображения состоят из пикселей, каждый из которых описывается компонентами цвета (тот же RGB, например) и описанием канала. Каждый параметр обычно изменяется в пределах определенного диапазона. Самый простой формат - BMP. Например, 24-битный BMP предоставляет нам три используемых байта на пиксел для описания цвета. Теперь зададим себе вопрос: что будет, если мы изменим каждый (или некоторые) компонент цвета на 1. Человек заметит это? Определенно, может и заметить, но только на однородной по цвету картинке. А если это натуральная фотография с большим количеством деталей (например, трава, пейзаж и тд), то человек просто не в состоянии обратить внимание на измененный пиксел. Тем более, в случае, когда он и не подозревает об этом. Таким образом, изменение всего лишь 1 бита (естественно, младшего) на компонент в картинке размером 1024х768 дает нам битовое пространство в 1024х768х3= ~2.36 миллиона битов! = ~ 300 килобайт(!) информации на файл. Т.е, грубо говоря, 1/8 размера файла. Заметьте, и это - без изменения исходного размера файла, который, к тому же, может быть просмотрен любой программой как обычная картинка. Данная техника получила незатейливое название "изменение младших битов" и основана на том, что при незначительном изменении параметров в медиа-форматах органы чувств человека не могут отличить измененный контейнер от исходного. Более того, при выборе достаточно пестрой картинки и изменении двух младших битов на компонент, мы сможем удвоить объем скрываемой информации. Очевидно, что даже 300 КБ - это очень немало. Кстати, может случиться так, что при изменении даже двух битов их значения совпадут с исходными после наложения... Т.е. изменения вообще не будет, но благодаря "контракту" при записи мы сожем извлечь информацию. Выполняя курсовую в то далекое время, автору статьи:) удалось-таки реализовать свой мини-вариант файловой системы с поддержкой иерархии каталогов, атрибутами файлов, шифрованием с хэшированием и контролем доступа на таком битовом пространстве. И, естественно, "вьювер-интегратор" для всего этого хозяйства. Может возникнуть вопрос, а зачем применять еще и шифрование? Просто мы рассматривали вариант, когда _человек_ не видит разницы в контейнере... Но то - глаз, а что нам скажут математики? А они скажут, что есть возможность попытаться использовать эвристические алгоритмы для поиска информации. Конечно, для этого необходимо сначала отыскать подозрительный контейнер. Против этого приема тоже есть выход - замести следы. Можно использовать неявный контракт в формате записи и записывать биты сохраняемых данных не в прямом порядке, а по какому-либо алгоритму. Конечно, использование BMP в современном мире уже подозрительно само по себе, но при изучении других форматов техника будет не очень сильно отличаться по своему принципу. В зависимости от сложности формата будет отличаться только максимальный объем "полезной нагрузки". Теперь далее... Звук... Ухо плохо воспринимает высокие частоты, а после 20 кГц - и вовсе никак... Между тем, многие форматы сохраняют звук в более широком диапазоне, который не всегда доступен на слух. То есть - вуаля - может использоваться в тех же целях. Мы можем изменить немало битов в звуковых данных - и это будет практически неотличимо от других "шумов". Все дело - в контракте! Мы-то знаем, как извлечь данные из такого "шума". Так как звуковые файлы имеют гораздо больший размер, то в них можно единовременно сохранить намного больше информации. Может дойти до парадокса, что в картинке мы можем сохранить другую картинку, в звуке - другой звук... Объем-то позволяет (без изменения размера исходного файла!). Наверное, многие догадались, что нас ждет с видео, где количество шума может быть еще бОльшим. Правильно: можно использовать как минимум ключевые кадры в качестве контейнеров. Поле для деятельности в случаях использования звука и видео намного более широкое, чем с графикой. Ведь в видео есть еще и звуковая дорожка! Да и обнаружить такую информацию будет намного сложнее. Да, есть еще один способ. Это скрытие текста в тексте. Т.е. когда по определенному алгоритму из текста-контейнера (может быть что угодно, любой связный текст) извлекаются символы для составления скрываемого сообщения. Но этот способ требует поистине творческого подхода при низкой отдаче. Поэтому развития, естественно, в цифровом мире не получил. При наличии таких-то собратьев, как графика, звук и видео. Замечу, что все виды контейнеров предполагается возможным использовать по их прямому назначению: картинки - смотреть, звук - слушать и т.д. И, напоследок, хотелось бы рассказать о том, какое продолжение получает стеганография. В статье нигде не упоминалось, но данный вид скрытия информации может быть и полезным в широком смысле. Один из таких вариантов - это цифровая авторская подпись. Стоит отметить, что после модификации контейнера вероятность потери данных при пересохранении файла-контейнера достаточно велика. Однако, потенциально автор может доказать авторство своей работы, скрыв свою подпись внутри самой работы. Как обычно, человеческий разум не знает предела... появились методы, которые позволяют восстановить скрытую информацию в графике даже после ее распечатки и (!) последующего сканирования. На этом завершаю свой "обзор" методов стеганографии... Хотя, поле для мыслей и применений в этой области действительно большое.

Скрытие информации методом криптографического преобразования заключается в преобразовании ее составных частей (цифр, букв, слогов, слов) к неявному виду с помощью специальных алгоритмов и кодов ключей. Незащищенное конфиденциальное информационное сообщение зашифровывается и тем самым преобразуется в шифрограмму, т. е. в закрытый текст или графическое изображение документа. Для ознакомления с шифрограммой применяется обратный процесс: декодирование (дешифрование). Использование криптографии является одним из распространенных методов, значительно повышающих безопасность передачи данных хранящихся в удаленных устройствах памяти, а также при обмене информацией между удаленными пользователями и объектами.

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

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

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

Основные требования, предъявляемые к методам защитного преобразования:

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

ь объем ключа должен быть оптимальным для запоминания и пересылки;

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

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

ь длина зашифрованного текста не должна превышать длину исходного текста;

ь необходимые временные и финансовые затраты на шифрование и дешифрование информации должны определяются требуемой степенью защиты информации.

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

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

Множество современных методов защитных преобразований можно классифицировать на четыре большие группы:

I. перестановки - заключается в том, что входной поток исходного текста делится на блоки, в каждом из которых выполняется перестановка символов;

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

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

IV. комбинированные методы - могут содержать в себе основы нескольких методов.

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

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

Все перечисленные методы относятся к так называемому симметричному шифрованию: один и тот же ключ используется для шифрования и дешифрования.

В последнее время появились методы несимметричного шифрования:

один ключ для шифрования (открытый), второй -- для дешифрования (закрытый).

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

Четвертое правило является еще одним шагом к укреплению тоталитарного режима в обществе модулей: требуется не только, чтобы любые переговоры ограничивались лишь несколькими участниками и были немногословными; необходимо, чтобы такие переговоры были публичными и гласными!

Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B .

За этим правилом стоят критерии:

  • Декомпозиции и композиции. Если нужно разложить модуль на несколько подмодулей или компоновать его с другими модулями, то любая внешняя связь должна быть ясно видна.
  • Непрерывности. Должно быть очевидно, какие элементы могут быть затронуты возможным изменением.
  • Понятности. Как можно истолковывать действие модуля A , если на его поведение может косвенным образом влиять модуль B ?

Одной из проблем, возникающих при применении правила Явных Интерфейсов, является то, что межмодульная связь может осуществляться не только через вызов процедуры; источником косвенной связи может быть, например, совместное использование данных ( data sharing ):


Рис. 3.9.

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

Скрытие информации

Правило Скрытия Информации можно сформулировать следующим образом:

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

Применение этого правила означает, что каждый модуль известен всем остальным (то есть разработчикам других модулей) через некоторое официальное описание, или так называемые общедоступные (public) свойства.

Конечно, таким описанием может быть весь текст модуля (текст программы, текст проекта): он и обеспечивает правильное представление о модуле, поскольку это и есть модуль! Но правило Скрытия Информации устанавливает, что в общем случае это не обязательно: описание должно включать лишь некоторые из свойств модуля. Остальные свойства должны оставаться не общедоступными, или закрытыми (секретные) (secret) . Вместо терминов - общедоступные и закрытые свойства - используются также термины: экспортируемые и частные (скрытые) (private) свойства. Общедоступные свойства модуля известны также как интерфейс (interface) модуля (не следует путать с пользовательским интерфейсом системы программирования).

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

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


Рис. 3.10.

В качестве характерного примера рассмотрим процедуру поиска по ключу атрибутов, хранящихся в таблице, такой как картотека личного состава или таблица идентификаторов компилятора. Эта процедура существенно зависит от способа представления таблицы - последовательный массив или файл, хэш-таблица, двоичное или индексное (B-Tree) дерево и т.д. Скрытие информации означает, что выбранный способ реализации таблицы не влияет на использование такой процедуры. Модули-клиенты не должны страдать от каких-либо изменений в реализации программы.

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

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

Однако эта рекомендация является нечеткой, так как не дано определение спецификации (specification) и реализации (implementation). Действительно, можно поддаться искушению, изменив определение на прямо противоположное, и утверждать, что спецификация состоит из общедоступных свойств модуля, а реализация - из его скрытых свойств! ОО-подход обеспечит намного более точные рекомендации на основе теории абстрактных типов данных.(См. "Абстрактные типы данных (АТД)" , в частности "Абстрактные типы данных и скрытие информации".)

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

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

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

Одной из причин вышеупомянутого недопонимания является сам термин "скрытие информации" ("information hiding"), который наводит на мысль о защите физического характера. В этом смысле предпочтительным, по-видимому, мог бы явиться термин "инкапсуляция" ("encapsulation"), иногда используемый в качестве синонима скрытию информации, однако в нашем обсуждении будет по-прежнему использоваться общий термин "скрытие информации".

Из этого обсуждения следует, что ключом к скрытию информации являются не решения по организации доступа к исходному тексту модуля в рамках управления проектом или маркетинговой политики, а строгие языковые правила, определяющие, какие права на доступ к модулю следуют из свойств его источника. В следующей лекции показано, что первые шаги в этом направлении реализованы в таких "языках с инкапсуляцией" как Ada и Modula-2. Объектно-ориентированная технология программирования приведет к более полному решению проблемы 5По умолчанию, "Ada" всегда означает не более новую версию Ada 95, а наиболее распространенную форму этого языка (версия 1983 года.). Обе версии рассмотрены в лекции 15 курса "Основы объектно-ориентированного проектирования ".