Пятнадцать лет назад на dxdt.ru появлялась, например, записка про историю со штатовским разведчиком U-2:

Архивное фото от NASA, запечатлевшее самолёт U-2 в “поддельной” раскраске, обозначающей принадлежность самолёта к NASA. Как сообщает само агентство, именно этот самолёт был представлен 6-го мая 1960-го года новостной прессе: якобы такие самолёты NASA использует для наблюдения за погодой. На самом же деле никаких U-2 тогда в распоряжении у NASA не имелось, а использовались эти высотные самолёты ЦРУ для разведывательных полётов над территорией СССР.

Полностью: https://dxdt.ru/2007/08/13/533/



Комментировать »

Технический Центр Интернет (ТЦИ) открыл российский общедоступный удостоверяющий центр (называется “Центр сертификации”) TLS: https://tlscc.ru/ (бета-версия).

Центр позволяет выпускать TLS-сертификаты как с ECDSA, так и с ГОСТ-подписью. Чтобы заказать сертификат, требуется зарегистрироваться на сайте. Для подтверждения права управления доменным именем можно использовать DNS (размещается TXT-запись с кодом) или веб-сервер (публикуется текстовый файл). Однако нужно учитывать, что действующие корневые ключи УЦ не входят в дистрибутивы браузеров (возможно, пока что не входят), поэтому для использования сертификатов их придётся добавить вручную.



Комментировать »

Десять лет назад на dxdt.ru появлялась, например, заметка про спуфинг сигналов спутниковых навигационных систем:

Теперь предположим, что навигационная система использует несколько “внешних” источников навигационной информации. Например, GPS + ГЛОНАСС. С одной стороны, такая система может обнаружить расхождение между показаниями, если GPS “подспуфили”. Но не ясно, что в таком случае этой системе делать? Она не может определить, происходит ли спуфинг GPS или, наоборот, ГЛОНАСС. И почему, кстати, GPS заслуживает меньшего доверия, чем ГЛОНАСС?

Вообще, про спуфинг GNSS я раньше писал нередко, в том числе, на страницах dxdt.ru – вот, например, весьма подробная записка по теме: “Подделка сигнала GPS (GPS-спуфинг)“.



Комментировать »

В продолжение предыдущей записки, про сертификаты от Let’s Encrypt. RSA и ECDSA – это распространённые в Интернете криптосистемы, которые используют различную математическую основу. ECDSA имеет целый ряд преимуществ. Однако в случае TLS-сертификатов существенный смысл в использовании ECDSA возникает тогда, когда вся цепочка сертификатов использует эту криптосистему.

Дело в том, что валидация (то есть, процесс установления подлинности) серверного сертификата подразумевает проверку подписи на одном или нескольких других сертификатах – это сертификаты удостоверяющих центров (УЦ). Технически, можно серверный (то есть, оконечный) сертификат с ECDSA-ключом подписать при помощи RSA. Именно так и делает Let’s Encrypt. При этом корневой доверенный сертификат с ECDSA у них уже есть, но вот оконечные сертификаты с ECDSA для обычных пользователей не выпускаются. Допускаю, что я не нашёл, где такую возможность включить, но, на мой взгляд, для оконечного сертификата с ECDSA автоматом должна выбираться вся цепочка с ECDSA – использование RSA, в этом случае, выглядит весьма странно (впрочем, учитывая, что сейчас 2022 год, RSA и в других случаях выглядит странно). Тем не менее, сертификат для dxdt.ru, который я вынужден был выпустить через Let’s Encrypt, содержит RSA-подпись. Ничего не поделать. Раньше, когда были доступны и другие УЦ, я использовал PositiveSSL, для которого есть ECDSA-цепочка.



Комментировать »

Поскольку добывать платные долгоживушие сертификаты от “хорошо известных УЦ”, корни которых есть в браузерах, стало очень неудобно, да ещё и по совсем неадекватным ценам (это связано с общим современным состоянием интернетов и, в частности, применимо к российским пользователям и доменам внутри .RU), поменял сертификат dxdt.ru на Let’s Encrypt. В этом бесплатном УЦ пока что .RU не заблокировали. Не факт, конечно, что это надолго (не заблокировано), но там и сертификаты-то по три месяца. Кстати, довольно занятно будет, когда сертификаты .RU перестанет выдавать и Let’s Encrypt – почти вся зона .RU, в смысле веб-серверов, использует сертификаты именно этого УЦ.

При переходе на Let’s Encrypt удалось даже без проблем применить особый ключ ECDSA, который я специально подобрал (запись открытого ключа содержит некоторую hexspeak-подстроку в самом начале; если вы, вдруг, интересуетесь экзотической занимательной арифметикой на эллиптических кривых и умеете смотреть серверные ключи TLS-сертификатов (это несложно сделать браузером), то обратите, как говорится, внимание). Но всю цепочку в ECDSA Let’s Encrypt делать отказался – этим пришлось пожертвовать.



Комментировать »

Заметка на dxdt.ru из 2009 года, рассказывающая о том, как идентифицировать пользователя приложения по отметкам геолокации:

Прежде, отметим один момент: формальной анонимности пользователя вовсе не противоречит создание на сервисе уникального аккаунта, привязанного к данной копии программы. Это необходимо и для обновлений, и для придания устойчивости системе в целом (помогает бороться с “поддельными запросами” злых хакеров и т.д.) Только по аккаунту личность пользователя установить нельзя.

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

За прошедшие годы актуальность только выросла: вспомните про суперпопулярные нынче приложения для “анонимного отслеживания контактов”.



Комментировать »

(Заметка первоначально опубликована в Facebook, 19/05/2020.) Я вот так устроил, что один сервис, проверяющий TLS, использует специально сконструированное сообщение ClientHello TLS 1.3 (см. скриншот) с посланиями внутри. Небольшая хитрость состоит в том, что там не только поля SessionID и ClientRandom с сообщениями, но и ключ для Диффи-Хеллмана (ECDH) на кривой P-256 – с посланием. Ключ – это два числа, но они должны задавать точку кривой, и хорошие реализации TLS проверяют, что ключ принадлежит кривой. Конечно, вычисление второй координаты Y по известной X-координате – никакой проблемы не составляет, но пришлось урезать пару символов, так как число приводится по порядку базового поля. У тех, кто знаком с ECDH, сразу возникнет вопрос – решил ли я попутно задачу дискретного логарифмирования для P-256? Но нет (а если бы решил, то сообщил бы об этом более занятным способом). Дело в том, что реально в этом сканере общий секрет не нужен, поэтому ответный ключ сервера просто игнорируется. (Конечно, вряд ли кто-то ещё это всё видит в трафике. Но при отладке – помогает.)



Комментировать »

А вот десять лет назад, в мае 2012 года, на dxdt.ru, например, была опубликована заметка про автономный персональный навигационный компьютер:

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



Комментировать »

Запись чисел при помощи цифр различных систем счисления нередко приводит к недопониманию у тех, кто не очень хорошо представляет себе разницу между числами и их записью. Например, могут предположить, что 11 и 0x11 (в шестнадцатеричной записи, далее такая запись обозначается привычным префиксом) это одно и то же число, ну, как 7 и 0x7. Нетрудно наткнуться и на смешение свойств числа и его записи: то есть, на неверное представление о том, что какие-то свойства чисел соответствуют именно записи (запутывающее сочетание 0x100 == 2^8). Впрочем, всё это не мешает занимательным свойствам позиционных систем счисления интересным образом преобразовываться при переходе от одной системы к другой, сохраняя именно запись (то есть, цифры).

Так, если 1001001 умножить на 321, то получим 321321321. Почему? Очевидно: мы умножаем (10^6 + 10^3 + 10^0) на (10^2*3 + 10^1*2 + 10^0*1), то есть (10^6 + 10^3 + 10^0)*321. Известный, пусть и не очень широко, факт: всякое число, содержащие ровно три одинаковых тройки цифр в своей записи, делится на 333667. Примеры:
321321321/333667 == 963 == 3^2 * 107
111111111/333667 == 333 == 3 * 111
701701701/333667 == 2103 == 3 * 701

(Конструкция, конечно, переносится и на кратные записи, то есть, когда количество триплетов кратно трём.)

Выглядит занимательно. Причина в том, что на 333667 делится 1001001 == 3*333667. А 333667 – простое число. В записи 333667 нетрудно увидеть поразрядные “переносы единицы” при умножении на три. Можно ли найти число с такими же свойствами в шестнадцатеричной записи? Можно. Если в десятичной записи 3*3 == 9 == 10 – 1, где 10 – основание системы, то в шестнадцатеричной аналогом будет 3*5 == 15 == 0x10 – 1. Обратите внимание, что здесь 0x10 шестнадцатеричная запись числа 16, основания системы. Число другое, но нам здесь важны как раз некие свойства записи (а именно – позиция единицы). Искомое число – 0x555aab. Заметьте, что шестнадцатеричное 0xa равно 10 в десятичной системе, то есть, 5*2 (так же как и 3*2 == 6). Проверяем: 0x555aab * 0x3 == 0x1001001 (но это 16781313 в десятичной записи). Поэтому 0x321321321 делится на 0x555aab, а результат равен 0x963 (см. примеры в десятичной системе выше). Однако найденное нами “опорное” число хоть и полностью подходит по “свойствам” записи, но является составным: 0x13*0x25*0x49*0x6d == 0x555aab.

А вот в восмеричной системе ситуация иная. Число 0o1001001 (префикс 0o – обозначает восмеричную запись) – простое, а именно – 262657 == 8^6 + 8^3 + 8^0. Поэтому не получится найти делитель, который подходил бы для построения конструкции, аналогичной десятичной и шестнадцатеричной системам. Интересно, что число 46656216001 == 60^6 + 60^3 + 60^0 тоже простое. Это означает, что и в древней шестидесятеричной системе конструкция не сработает. Что ж, зато в десятичной системе 296296296296296296296296296/333667 == 888000000888000000888. Проверьте на калькуляторе.



Комментировать »
Навигация по запискам: « Позже Раньше »