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

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

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

Конечно, ничто не мешает и исполняемый код «пропатчить», убрав все проверки, но для этого злоумышленнику потребуется больший скилл. Этот вариант мы не будем рассматривать.

В общем, стоит задача программно реализовать (в userspace) один аппаратный интерфейс через дерганье gpio-выводами. Вариант через sysfs даже не рассматривался - медленно до безобразия (взять хотя бы то, что у интерфейса есть параллельная двунаправленная шина, и придётся побитово загонять в неё данные и побитово же переключать направление). Напрашивается прямой доступ к регистрам контроллера через /dev/mem.

Уж сколько дней ломаю голову, ситуация следующая. Через sysfs все 11 нужных пинов работают (во всех режимах). И если предварительно через sysfs настроить пин на выход (испробовал на трёх), то и через /dev/mem получается им помигать/прочитать. А вот переключить направление пина (вход или выход) прямой записью в регистр не удаётся никак - значение записывается, но как будто не в регистр, а в какой-то кэш. И остаётся в этом кэше даже после переоткрытия memory mapping и даже при следующем запуске программки. Но стоит поменять направление порта через sysfs, как значение в этом регистре обновляется тем, что туда записалось через sysfs.

Думал, может, я чего-то не так делаю с этим отображением. Поставил из репозиториев утилиту devmem2. С ней всё то же самое. Далее предположил, что, быть может, направление пина не так просто переключается. Или подумал, вдруг направление порта хранится в поле структуры и не синхронизируется со значением регистра. Но нет, в структурах только указатели на функции, которые обращаются к этим регистрам через readl/writel.

А теперь самое главное. Решил пока вырубить полностью gpio controller через device tree на всём порту, с которым работаю. Пробую опять помигать через devmem2. Теперь получается и мигнуть, и попереключать направление… но только младшими 8-ю битами. В остальные 24 бита значения пишутся (и считываются), но нужного действия не оказывают. Пока такое подозрение, что запись uint32 в отображение инициирует побайтовое копирование, регистры же могут быть перезаписаны только целиком по 4 байта.

Кто что может посоветовать, кроме как свой модуль ядра писать? Куда копать, как быть?

P. S. Платформа freescale imx6dl, ядро 3.14.

Доброго времени суток. Пытаюсь кросскомпилировать в Убунте под OpenWrt и запустить в последнем megatools (консольные утилиты для заливки файлов в облако mega.cz), удалось собрать нормально устанавливаемый ipk-пакет, но при попытке запустить любую из утилит выдаётся:

root@OpenWrt:/tmp# megals
megals: symbol '__stack_chk_guard': can't resolve symbol
megals: symbol '__stack_chk_fail': can't resolve symbol

С кросскомпилятором всё в порядке – HelloWord компилируется и запускается (я ведь правильно думаю, что если были бы проблемы с libc, тогда б функции stdio.h не работали?), тест glib2 тоже работает (работа со списком GSList).

(Добавлено)
Прояснилось уточнение – проблема, похоже, кроется в glib2, причём только в двух его библиотеках: gio и gobject. Стоит прилинковать хотя бы одну из двух этих библиотек к HelloWorld (даже не подключая ничего в коде), так HelloWorld перестаёт запускаться с вышеописанной ошибкой. Остальные 3 библиотеки подключаются нормально. Ещё раз перепроверил отсутствие этих якобы «недостающих» функций в зависимостях. В чём причина? Такое ведь наблюдается как с самостоятельно собранной версией, так и с версией с репозитория.

Всем доброго времени суток.

Кто-нибудь сможет помочь, подсказать, как собрать Mono под armhf под Debian на Freescale imx6dl? Исходники брал как с официального гита, так и из tar-архивов с офсайта mono. Перепробовал ветки 3.8.0, 3.10.0, 3.12.0 – не собирается ни одна (master, говорят, вообще на arm не работает). Собирал по инструкции отсюда и отсюда, прямо на «пациенте» безо всяких виртуалок и qemu-arm-static. Пробовал и через make get_monolite_latest && make EXTERNAL_MCS=”<путь к mcs из monolite>” и через предварительно установленный из репозиториев Mono.

Какие бы ключи, опции, ветки ни пробовал, во всех случаях процесс через ~ 2 часа доходит до успешной сборки компилятора mcs.exe и отваливается при попытке им что-либо откомпилировать (если быть точным, то mscorlib.dll для .net 2.0) без конкретных ошибок.

Такое ощущение, что этот mcs.exe компилируется как-то некорректно. Его не удается вручную заставить работать ни через установленный в системе mono (с ключом --runtime=<…>, с переменной окружения MONO_PATH), ни через mono_wrapper, который используется для вызова этого mcs.exe из make (как я понял mono_wrapper – это урезанная версия mono, собираемая специально для запуска компилятора mcs.exe). Какие опции ему не подавай – он просто никак отвечает на вывод, не реагируя ни на --help, ни на --version, ни даже на «мусор». В то же время mono_wrapper хотя бы реагирует на --help и умеет ругаться на неизвестные опции. Другие утилитки, собранные вместе с mcs.exe и лежащие рядом, запускаются через mono_wrapper нормально, пишут себе что-то на терминал.

Сам же процесс компиляции завершается такими вот нехитрыми строками (это с make V=1):

make[8]: Entering directory `/usr/src/mono-3.8.0/mcs/class/corlib'
MONO_PATH="./../../class/lib/build:$MONO_PATH" /usr/src/mono-3.8.0/runtime/mono-wrapper  ./../../class/lib/build/mcs.exe /codepage:65001 -unsafe -nostdlib -nowarn:612,618 -d:INSIDE_CORLIB -d:LIBC  -d:NET_1_1 -d:NET_2_0 -nowarn:1699 -nostdlib -lib:./../../class/lib/net_2_0  -debug -optimize  /noconfig -resource:resources/collation.core.bin -resource:resources/collation.tailoring.bin -resource:resources/collation.cjkCHS.bin -resource:resources/collation.cjkCHT.bin -resource:resources/collation.cjkJA.bin -resource:resources/collation.cjkKO.bin -resource:resources/collation.cjkKOlv2.bin --runtime:v2 -target:library -out:../../class/lib/net_2_0/mscorlib.dll  @corlib.dll.sources
make[8]: *** [../../class/lib/net_2_0/mscorlib.dll] Error 1
make[8]: Leaving directory `/usr/src/mono-3.8.0/mcs/class/corlib'
make[7]: *** [do-all] Error 2
<<Leaving directory 7 раз>>
make: *** [all] Error 2