ЭЦП и биометрия

[epros]

mihaild в сообщении #1709978 писал(а):

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

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

[Dmitriy40]

epros в сообщении #1710011 писал(а):

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

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

[epros]

Dmitriy40 в сообщении #1710016 писал(а):

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

А как Вы из этой штуки сделаете пару - закрытый и соответствующий ему открытый ключ?

[Dmitriy40]

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

epros в сообщении #1710017 писал(а):

А как Вы из этой штуки сделаете пару - закрытый и соответствующий ему открытый ключ?

Ровно как и из Вашей случайной последовательности. Это просто метод однонаправленного (без возможности восстановления исходных данных) получения воспроизводимой случайной последовательности любой длины из достаточно длинного легко запоминающегося текста.
Фактически это такое хэширование (вместо например MD5 или SHA256), только произвольной длины и достаточно простое.
Если надо превратить эту штуку в полупростое число (произведение ровно из двух разных простых чисел), как обычно требуется в методах шифрования, то делим биты на чёт/нечёт, компонуем в два битовых числа и ищем следующее простое число для каждого - получаем два простых числа для перемножения. Можно навернуть проверку что числа получились не слишком "угадываемыми", это уже по желанию.

[mihaild]

epros в сообщении #1710011 писал(а):

В сущности, разница с запароленным файлом ключей невелика.

Это правда. Единственное существенное преимущество - устойчивость к перебору.

epros в сообщении #1710017 писал(а):

А как Вы из этой штуки сделаете пару - закрытый и соответствующий ему открытый ключ?

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

[Dmitriy40]

mihaild в сообщении #1710019 писал(а):

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

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

[epros]

Dmitriy40 в сообщении #1710018 писал(а):

Ровно как и из Вашей случайной последовательности.

Утилиты генерации ключей может быть и умеют, а я не умею.

Dmitriy40 в сообщении #1710018 писал(а):

Фактически это такое хэширование (вместо например MD5 или SHA256), только произвольной длины и достаточно простое.

Хеш-функциями я как раз пользоваться умею. И поверьте, что это будет лучше использования архиватора.

mihaild в сообщении #1710019 писал(а):

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

Это где? Как?

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

[mihaild]

epros в сообщении #1710021 писал(а):

Это где? Как?

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

epros в сообщении #1710021 писал(а):

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

Редактору не нужно демонстрировать процедуру генерации ключей, ему нужно докаазть, что у Вас есть приватный ключ.
Для этого делается следующее. Пара публичный-приватный ключ генерируется из пароля по любому удобному Вам алгоритму. Ему не обязательно быть популярным, достаточно, чтобы Вы его знали, и смогли впоследствии запустить еще раз. Вы подписываете материал своим приватным ключом, выкладываете публичный везде где можно.
В редакции редактор даёт Вам на подпись документ "я автор этого текста, ЛММ клянусь". Вы со своего устройства, на котором есть Ваш приватный ключ (или нет ключа, а есть процедура генерации выше) подписываете этот документ и отдаете подпись редактору. Редактору для проверки достаточно знать, как работает RSA.

[epros]

mihaild в сообщении #1710026 писал(а):

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

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

[mihaild]

epros в сообщении #1710030 писал(а):

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

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

Вроде бы завернутого в утилиту такого нет, но это 10 строк кода.

[epros]

mihaild в сообщении #1710035 писал(а):

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

Правильно ли я понял, что эта функция должна возвращать байтовую строку любой длины?

mihaild в сообщении #1710035 писал(а):

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

Это, вроде, наименование алгоритма. А реализация его существует?

mihaild в сообщении #1710035 писал(а):

Вроде бы завернутого в утилиту такого нет, но это 10 строк кода.

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

[mihaild]

epros в сообщении #1710064 писал(а):

Правильно ли я понял, что эта функция должна возвращать байтовую строку любой длины?

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

epros в сообщении #1710064 писал(а):

А реализация его существует?

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

epros в сообщении #1710064 писал(а):

Алиса мне тоже говорит, что утилиты нет. И это плохо, потому что придётся заниматься программизмом и хранить код

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

[epros]

mihaild в сообщении #1710069 писал(а):

Гораздо лучше обратный вариант - сгенерировать пару ключей честно случайно, а потом запоминать какой-нибудь BIP39 от приватного ключа.

Это ведь Bitcoin Improvement Proposal 39? Насколько я понял, это стандарт создания мнемонических фраз для генерации ключей. Но как это поможет сгенерировать мнемоническую фразу по уже готовому ключу?

[mihaild]

epros в сообщении #1710103 писал(а):

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

Там два преобразования: сид $\to$ фраза, и фраза $\to$ ключ. Первое преобразование универсальное и применимо к любым бинарным данным.

[epros]

mihaild в сообщении #1710109 писал(а):

Там два преобразования: сид $\to$ фраза, и фраза $\to$ ключ.

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

Плохо, что готового и широко распространённого решения в виде приложения или утилиты нет. Дописывать собственный код - это довольно коряво.