dxdt.blog: занимательный интернет-журнал

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

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

Есть способы, позволяющие координаты уточнить. Не менее простой, чем запрос в “геобазу”, способ: можно прямо попросить пользователя самостоятельно указать собственное местоположение (есть популярные сервисы в Интернете, предлагающие передать такую информацию). А можно запросить точные данные автоматически, если у пользователя устройство, с которого он ходит по просторам глобальной Сети, оборудовано приёмником GPS или другим инструментом для определения собственных координат. Ну, да, понятно, что пользователь должен там какие-то соглашения принять – но вряд ли многие отказываются. Таким способом работают провайдеры сервисов для разных приложений в смартфонах. И тут требуется собственная база данных, куда записывается собранная информация.

Другой вариант: со стороны сервера можно построить (“оттрассировать”) сетевой маршрут до клиентскогого IP-адреса (с некоторой точностью, понятно). Если точно известно местоположение последнего перед клиентом узла, то можно предположить, что и клиент где-то неподалёку от этого узла находится. Опять же, работает не во всех случаях, но в большинстве.

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

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

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

Ещё один источник сведений, правда, косвенный, это DNS. Так как обычный пользовательский компьютер выполняет поиск в DNS при помощи резолвера доступного в данный момент интернет-провайдера, и эти резолверы могут меняться, то, отслеживая запросы на подконтрольных NS (серверах имён), можно вычислить и провайдера, и дополнительные сведения о местоположении пользователя. Такой подход особенно помогает, если пользователь ходит из-за NAT, то есть, снаружи виден под некоторым “общим” IP-адресом.

И, похоже, это ещё не все способы.

Зарисовки практического освоения IPv6. 8 июня проводится всемирный день IPv6. Соответственно, нужно подготовиться. Что выясняется: во-первых, шишки набиваются при внедрении нового протокола на пользовательских рабочих местах; в теории всё ПО (в том числе ОС) готово и должно работать, на практике оказывается, что по отдельности работает, а вот чтобы вместе – нет, тут наблюдаются неожиданные эффекты, типа автоматического получения ОС Windows сразу нескольких адресов для одного интерфейса, потому что так были восприняты анонсы ближайшего роутера.

Во-вторых, админы пока не воспринимают новый протокол как неотъемлемую часть админской реальности: нужно понимать, что в ближайшие годы придётся жить с двумя протоколами, соответственно нужно “задвоить” все навыки и прикладные настройки. На практике выходит, что для одного и того же прикладного использования (например, отправка электронной почты), где IPv4-доступ настроен раньше, при вводе IPv6 внести соответствующие изменения в контроль доступа забывают. Хотя, казалось бы, для одной и той же физической машины, получившей IPv6 в дополнение к v4, нужно автоматом сохранить все прикладные доступы.

В-третьих, очень интересной станет жизнь у веб-разработчиков: у многих скриптов будет начисто сносить крышу после того, как веб-сервер вместо привычных IPv4 принесёт в переменные окружения новую запись новых адресов. Там проблем уже сейчас просматривается много, а ещё больше запрятано внутри всяких фильтров и валидаторов. Ещё веселья добавит только что упомянутый факт, что речь не идёт о пересаживании с v4 на v6 – будет сразу два протокола.

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

Вот.

Занятно: в консорциуме W3C недавно создана рабочая группа, задача которой состоит в создании API и стандартов для прямых межбраузерных коммуникаций. Прямых – в том смысле, что браузеры для связи на прикладном уровне не используют промежуточных (центральных) серверов. Получается децентрализованная система, построенная на базе самих браузеров, и таким образом реализующая некий сервис для пользователей (идейно это всё аналогично сетям P2P, понятно).

Так, в описании задач упомянутой группы сказано про аудио-, видеосвязь между пользователями. Можно вспомнить, что в Skype как минимум для установления соединения необходим центральный сервер. Есть системы коммуникаций на базе Интернета (всякие ICQ тому пример), которые вообще работают только через центральный сервер. В W3C думают над P2P-заменой такому безобразию.

Возможно, аудио-, видеосвязь станут тут только началом. Если вообще что-то придумают, конечно. Интересно, что такие сервисы в некотором роде формируют противовес всяким новомодным “облачным решениям”: вся техническая база находится на пользовательском компьютере и при наличии некоторой “среды связи” такой пользователь может общаться с другими. С другой стороны, пользователи всё равно зависят от поставщика услуг связи (“центра”): кто-то ведь им предоставил доступ к Интернету?

(Тему подсказал Vladimir Dyuzhev.)

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

Другой вариант напрашивается: использовать мощь “дополненной реальности” и для вывода визуальной информации обо всех доступных для измерения электромагнитных полях, окружающих пехотинца. Многие “техногенные” поля не так сложно измерить с достаточной точностью. Но вот с полезным применением полученной информации возникают трудности: поле, понятно, измеряется возле самого пехотинца; при этом вычислить, какая именно конфигурация полей в окружающем пространстве (пусть в ближайшем), привела к возникновению результата измерения в данной точке – обычно невозможно. Для того, чтобы можно было что-то сказать о распределении полей и их источников требуется проделать измерения в нескольких точках, и синхронизировать результаты по времени. Да, наверное, можно было бы сделать довольно большую антенну, распределив её по обмундированию. Но это чрезвычайно сильно увеличивает заметность пехотинца для радаров, что плохо.

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

Выходит, что “накладывание картинки” на изображение реальности, в случае с анализом электромагнитных полей, имеет очень ограниченное применение: требуется, чтобы была подробная информация о характеристиках источника поля – вот тогда можно что-то полезное вычислить в режиме онлайн. Другими словами, если сцену подсвечивает самолёт ДРЛО или, например, спутник GPS, то можно “увидеть” скрытые за стенами и кустами объекты. А если никто не подсвечивает, то и толку от электромагнитного слоя в интерфейсе “дополненной реальности” не много.

Занятно, что сильно поутихла тема “умной пыли”, очень популярная ранее. Речь о микроскопических электронных устройствах, каждое из которых автономно реализует некоторые сложные полезные функции под управлением микрокомпьютера и умеет поддерживать связь с внешним миром. Устройства действительно миниатюрные: по традиции, не более кубического миллиметра объёмом. Отсюда и название – и пыль, и умная.

Впрочем, чтобы стать настоящей пылью элементы должны быть ещё меньше, чем кубический миллиметр. Например, раз в двадцать меньше по объёму. Пыль можно использовать по всякому, это описано и у фантастов. Интересно отправить такую пыль по воздуху, вместе с облаками, исследовать вражескую территорию. Можно предположить, что кто-то наступил в “умную пыль”, она осталась на ботинках, и теперь легко отслеживать перемещение этого наступившего в пыль человека.

Понятно, что с созданием самой электроники микрокомпьютера, умещающегося в пылинку, особенных проблем сейчас быть не должно: транзисторы для “логики” давно научились делать маленькими, правильное проектирование позволит использовать разумный минимум транзисторов. Сложнее с модулем памяти, но, используя самые современные достижения, можно и достаточный объём памяти для кода и данных (мегабайты?) уместить в пылинку. Самая большая проблема – с электропитанием и источниками этого самого питания. Для пылинки нужен суперкомпактный источник. (С другой стороны, например, бактерии имеют размер много меньше подобной пылинки, но энергию накапливают.)

Вообще, подобную “умную пыль” можно реализовать в формате “пассивного автоответчика”. Такой проект даже вроде был. Идея в следующем: пылинки срабатывают при облучении их электромагнитным полем с заданной модуляцией, используя энергию этого поля измеряют заданные параметры окружающей среды, проводят свои внутренние вычисления и каким-то образом передают результат обратно (скорее всего, по оптическому каналу). То есть, подсвечивают такую пыль с борта самолёта локатором (как вариант), а специальные приёмники где-то на земле получают собранные данные. Если развить идею, то, скажем, пылинки мог ли бы работать при условии наличия любого подходящего электромагнитного поля достаточной напряжённости.

Другая трудность подобной пылинки – это оснащение её сенсорами. Можно представить, что где-то внутри пылинки разместился нанотехнологический акселерометр. Но он будет устроен очень непросто: потому что возникнет проблема с датчиками (а от гироскопа вообще придётся отказаться). Приёмник GPS, очевидно, не уместится, ни по антеннам, ни по накопительным цепям для сигнала – потому что требуется дополнительное питание. Довольно компактными могут быть световые оптические сенсоры, сенсоры температуры. И, пожалуй, всё. Не густо.

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

В общем, тема интересная. Но в публичности потеряла. Наверное, что-то уже сделали. Для ЦРУ, как вариант.

Часто в разных СМИ и даже в презентациях на популярных конференциях можно услышать про ботнеты, насчитывающие миллионы компьютеров. (Например, на РИФе называли кто 30 млн, кто 50 млн – в общем, получается, кто больше.)

Похоже, проблема тут вот в чём: благодаря резко возросшей вычислительной мощности миллион уже кажется не таким большим числом. Интересно, оставив в стороне степень достоверности оценок численности ботнетов (как там генерят эти стат. данные? кто знает, кто знает…), прикинуть, как может жить ботнет из миллиона компьютеров. Прикинуть можно на примере элементарных действий для такого ботнета.

Итак, если узлы ботнета-миллионника в течение суток придут равномерным потоком в центр за новыми указаниями, то это будет – около 12 запросов в секунду, минимум. Нужно брать место в дата-центре или арендовать мощности в сервисах типа Amazon EC. А для того, чтобы боты приходили в центр равномерно – должен быть реализован очень хитрый алгоритм распределения нагрузки.

Если узлы ботнета-миллионника обмениваются данными внутри и каждый перешлёт десяти другим один килобайт, то – трафик составит около 10 Гб. То есть, это такиой примерный трафик, который должен пройти по сетям, если ботнет обновляется по правильной технологии разновидности P2P. В зависимости от топологии размещения узлов ботнета и частоты обмена пакетами такой трафик может быть хорошо заметен в статистике интернет-провайдеров. Хотя, конечно, не является заметным в масштабах Интернета. Продолжим про трафик и вычислим 10 гигабайт другим способом: если для заражения одного компьютера требуется разовая пересылка кода червя, а этот код занимает 10 килобайт (сейчас “черви длинные”), то опять будут потрачены те же 10 Гб, состоящие только из данных программного кода. И никто из антивирусных компаний, выходит, не смог ничего выудить?

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

И это только теоретический устойчивый ботнет с числом узлов в миллион. Понятно, что для 30 млн – ситуация принципиально иная: рост сложности управления в подобных случаях не линеен.

Насколько можно преуспеть в реальности, показывает опыт добровольных сетей распределённых вычислений. Даже учитывая полное доверие и желание сотрудничать со стороны участников – сетей-миллионников здесь практически нет, и все те, которые есть, растут из старых, годами хорошо раскручиваемых, проектов, например, SETI@Home. Но в большинстве случаев, хороший результат – сотня тысяч участников.

В комментариях к записке, посвящённой военному снаряжению с сенсорами запахов, предлагают занятный вариант атаки на эти сенсоры: специальный “отравляющий” газ (запах). Логично. Оптические сенсоры можно “ослеплять”, используя яркий свет. Для вывода из строя “нюхателя” подходит специальным образом спроектированный газ, ну или какой-нибудь порошок, распространяющий атакующие “запахи” (хорошо известно, что есть такие вещества, работающие против собак).

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

Между прочим, нужно ожидать появления вредоносного кода в “дополненной реальности”, которой пичкают современные смартфоны. Очевидный путь заражения: QR-код с наклейки где-нибудь в метрополитене.

Обсуждали записку с цитатой про “пока браузеры делают не у нас…” (напомню: там речь примерно о том, что, якобы, если браузеры делаются где-то “не у нас”, то они обязательно содержат закладки, представляют угрозу и т.п.). Мнения, как говорится, разделились: некоторые готовы верить, что, действительно, для обеспечения безопасности наипервейшее значение имеет “родовое” происхождение браузера; но готовы верить – не все, и это хорошо. Вообще, основная хитрость тут в том, что необходимо оценивать весь цикл принятия браузера в эксплуатацию.

Предположим, что “борьба закладок” уровня “у нас/не у нас” в типовых “гражданских” браузерах, не являющихся специальным ПО – не вымысел. Тогда, если браузер делают “у нас”, то возможность появления в нём уязвимостей и даже закладок – всё равно остаётся. Ну, раз есть “борьба”, то её станут продолжать и после того, как география разработки скорректирована. Понятно, что для внесения закладок (а это саботаж, вообще говоря) потребуются другие инструменты, чем использовались бы (гипотетически) при внешнем происхождении браузера (там просто – дописали, что хотели). Но такие инструменты существуют. Что касается уязвимостей, то на их появление географическое место разработки браузера уж точно не влияет.

Следовательно, раз мы озаботились не просто переносом места происхождения браузера от “не у нас”, а действительно боремся с закладками и уязвимостями, то всё равно потребуется аудит безопасности вновь созданного браузера. Если делать всё согласно традициям, сложившимся в тех областях, где подобные подходы действительно оправданы, то аудит должна делать лаборатория, не просто независимая от разработчиков браузера, но, вообще говоря, не доверяющая этим разработчикам в вопросах создания браузеров. На первый взгляд, вопрос доверия тут может показаться некоторым перегибом. Но это не так. Предположим, что аудиторы полностью доверяют разработчикам. Тогда недобросовестные разработчики, при желании, смогут аудиторов дезинформировать, например, с помощью ложной документации – и аудит закладок/уязвимостей в браузере теряет смысл.

Но раз так, то возникает вопрос: а почему бы этой же лаборатории аудита не провести аудит браузера, сделанного “не у нас” и просто сертифицировать его? Такой вариант будет эффективнее, ведь внешний браузер уже готов, обкатан, отлажен и доступен для сборки в исходных кодах. Тем более, что развивать технологии автоматизированного аудита кода, позволяющих без опаски использовать чужие наработки (а также находить в них уязвимости/закладки; обратите внимание, какой это бонус!) – в нынешних условиях существенно полезнее, чем изобретение браузерного велосипеда.

Развитые и гибкие информационные системы сейчас сращиваются с не менее сложными механическими. Эти механические системы – они старые, традиционные, принадлежат другим отраслям, не к ИТ. Живой пример: современные автомобили. С некоторого момента сложность этих информационных систем оказывается достаточной для того, чтобы привлечь специалистов по информационной безопасности.

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

Аналитики-взломщики, добравшись до автомобилей, просто используют те же идеи, которые ранее обкатали, скажем, на банковских веб-сайтах. Посмотрите: отлично работает древний метод, основанный на эксплуатации безграничного доверия к данным, получаемым программой извне. Пусть даже это “извне” – относится к родным радиодатчикам автомобиля. То есть, в новом пространстве работает уже отлаженный инструментарий взлома. А средства защиты – почему-то каждый раз строят заново. При этом автомобиль – очень распространённый, повседневный и довольно опасный механизм, пока что не защищённый в информационном плане. Хотя, движение в направлении создания стандартов такой защиты уже началось.

Интересно, что станет развиваться быстрее – требования по информационной безопасности или проникновение информатизации во все классические механизмы? Одно дело – взломать компьютерную систему автомобиля при помощи специально подготовленного “музыкального” диска. А совсем другое, если технохакеры возьмутся за какой-нибудь “умный дом”. Вообще, эти “умные дома” – это очевидынй следующий шаг, после автомобилей. При этом в доме куда больше всяких потенциально уязвимых объектов: климатическая система, двери, окна и так далее.

Что ещё подобное можно “ломать”? Да всё что угодно. Дело в том, что ключевая тенденция – это превращение всех окружающих вещей в “умные вещи”. Поэтому и “ломать” станут всё подряд. И если сейчас люди склонны слепо верить гражданским GPS-навигаторам (которые, кстати, вообще никак не защищены от внешнего вмешательства с подменой координат), то что же говорить про “дополненную реальность”, которая транслируется прямо в “умные очки”? (А такие очки сделают в ближайшие годы.)

Посмотрим-посмотрим.

В новой, четвёртой, версии браузера Firefox, похоже, решили “смягчить” следование веб-стандартам в угоду исправлению одной надуманной “ошибки”. Речь о довольно хорошо известном методе определения средствами HTML, CSS и Javascript истории веб-сёрфинга для браузера посетителя веб-сайта.

Метод основан на том факте, что ссылкам (URL-ам), которые посещал пользователь, можно присваивать визуальное оформление, отличное от тех ссылок, которые “новые”. Понятно, что параметры визуализации ссылок на веб-странице можно определить средствами CSS (можно даже и без Javascript, но последний – сильно помогает). Далее через браузер прогоняется большое число ссылок, и выясняется, где данный браузер (а вообще говоря – пользователь) успел побывать.

Разработчики Firefox решили заботиться о приватных данных. И пошли самым типичным программистским путём: в новом браузере нельзя будет назначать для ссылок, в зависимости от “посещаемости”, разные визуальные атрибуты (кроме цвета). Точнее говоря, назначить-то в коде страницы можно, но браузер будет игнорировать определения. (А кроме того, обещают соответствующую измерительную функцию в Javascript – испортить.) То есть, часть предписаний стандартов – игнорируются. Для борьбы за history.

Да, на практике можно было бы поднять страницы, которые начали бы строить профили пользователей по истории посещений. Да, понятно, что остались другие методы определения истории веб-сёрфинга. Но интереснее другое: посмотрите, есть счётчики посещений веб-сайтов, размещаемые на веб-страницах; например, Google Analytics. Очевидно, что держатель такого счётчика может собирать историю походов браузера по сайтам (верно для тех сайтов, где установлен счётчик).

При этом, сомнительное игнорирование веб-стандартов разработчиками Firefox никак не помогает спасти пользователей от сбора их данных распространёнными счётчиками, где, кстати, такой сбор смотрится вполне логично – потому что нужен для рекламы. Занятно. (Да, можно отключить Javascript и загрузку изображений с заданных сайтов, но, на минуточку, – а чем это отличается от ситуации с “ошибкой” в CSS? Там тоже можно отключить.)

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

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

Продолжение такое: есть большой список вычислительно сложных математических проблем, решения которых, если только удалось их найти, легко проверяются. Можно предположить, что хитрый механический замок основан на одной (или нескольких, почему нет) из таких сложных задач. Наличие алгоритма быстрой проверки решения в этом случае означает, что можно решение, – точнее, физическое его воплощение, – использовать в качестве своего рода запирающего элемента. Возможно, это не совсем понятный момент. Речь вот о чём: мы используем тот факт, что гарантированно можно сделать элементарный чисто механический вычислитель, который сможет проверить правильность предложенного решения, и встроить такой вычислитель в замок в качестве механического свойства.

Что получается? Получается, что детали замка представляют собой физическое воплощение сложной задачи (годится что-то из области графов, или, скажем, поиска разбиений множества элементов – вообще, в теории сложности есть класс NP-полных задач, там большой выбор). Основная идея в том, что наш замок будущего не содержит единого простого запирающего элемента, наличие которого позволяет, пойдя от обратной задачи, легко найти конфигурацию “открыто”. Напротив, здесь очень много механических элементов (предположим, тысячи), и даже получив полную информацию об этих элементах и их конфигурации в положении “заперто”, для определения открывающей комбинации придётся решать задачу, положенную в основу замка. А её решение требует времени. Ключ для такого замка содержит закодированное в его свойствах решение “замочной задачи”. Замок, как мы выяснили, может чисто механически “проверить” верность предъявленного решения и, если оно верное, попутно приходит в состояние “открыто”.

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

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

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

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

Может, есть уже такие замки?