Bitcoin Forum

Реквестирую в тред профессиональных криптографов.
Где-то здесь на форуме поднималась уже идея криптования приватного ключа. Но в качестве инструментов предполагалось наличие шайтан-компьютера и использование с помощью оного бинарных методов шифрования нужной информации - отсюда файлы, криптоконтейнеры, и прочая неблагодатная хрень, котору нельзя заюзать с помощью каменнного топора, ручки и листа бумаги.
А если упороться до самого немогу и попытаться зашифровать так, чтобы для восстановления понадобился минимум инструментов - мозг и математика -?
Только мозг - исключается, так как запоминание в стиле brainwallet - то есть, непосредственное помещение в память исходной зубодробительной base-58 последовательности - это вам не вам не песни Киркорова, завязающие в мозгу помимо воли. Предполагается не запоминать исходный текст, а хранить в зашифрованном виде на самом виду у врага - например, в виде татуировки на правой груди, прямо под Маринкой в анфас.
Следовательно - плюс математика. Но математика такая, чтобы ее можно было просчитать, загибая пальцы - и максимум, на руках, не включая пальцы ног.
Я смог догадаться только до шифра гаммированием. Считаем исходный приватный ключ числом в base-58 и посимвольно складываем его с мастер-паролем (также в base-58) по модул 58. Операцию можно произвести буквально с помощью ручки, бумаги, и навыков сложения. С помощью тех же ручки, бумаги и навыков вычитания (и не забыв мастер-пароль)- можно расшифровать ключ. Имеем независимость от шайтан-компьютеров.
Вопрос - насколько криптостоек такой метод?
Я не криптограф. Почитал чайниковые статьи про криптографию - понял так, что идельно криптостойким является шифр с ключом (гаммой) - равным сообщению. Это позволяет нивелировать статистические особенности исходного текста, сделав его похожим на случайную последовательность.
Но истинно случайная гамма с длиной равной сообщению - это накладно и сложно (для бумаги и каменного топора точно уж не подходит), поэтому реальные шифры ее только моделируют.
Реальный потоковый шифр использует псевдослучайную бесконечную гамму, создавая ее с помощью ГСПЧ-алгоритма из начального ключа.
Реальный блочный шифр использут повторяущуюся гамму, но при этом кроме прямой замены использует перестановку внутри блока - и таким образом изменет статистические параметры исходного текста.

Я же предлагаю совсем тупо - никаких перестановок, никаких ГСПЧ-бесконечностей. Тупо повторяющаяся гамма (короче исходного текста), накладываемая на приватный ключ.
Я исхожу из того, что приватный ключ - сам по себе число случайное - следовательно, будучи зашифрованным случайной короткой гаммой - он не подвержен атаке, предполагающей, что исходный текст является осмысленным и, следовательно, имеет некие статистические особенности.
Ы?

Да, если

1  ключ близок к случайному
2  из него исключена контрольная информация(там вроде контрольная сумма есть)

то обычная XOR-ка с паролем вполне надежна.
(как вариант - арифметическое сложение по модулю 256, но там надо чтобы не угадали сам пароль)

Vladimir
PS  а не проще ли сам этот пароль использовать в качестве ключа и нигде не записывать?

PPS  к рейдам МВД/ФСБ за майнерами готовитесь? ;)
Это правильно, тока главное глоками не забыть запастись ;))

из исходного приватного ключа?

Судя по тому, что нашел в интернетах - приватный ключ это таки случайное число, аргумент эллиптической функции. Судя по этому, там не должно быть производной, зависимой информации. (контрольная сумма и идентификатор сети (пресловутая начальная единица, которая на самом деле ноль) - это особенности адреса Биткойн, aka хеша открытого ключа).
Тем не менее, на небезызвестном correct horse battery staple (http://brainwallet.org/)  и на усе пропало, шеу, усе пропало (http://directory.io/) - все  (вродя) приватные ключи начинаются с пятерки - нигде объяснение этой особенности не нашел. Разе что в исходные кишки протокола смотреть, но я не умею.

да



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

Vladimir

Работа над ошибками.
То, что я упорно называл здесь "приватным ключом" - на самом деле - WIF, Wallet Import Format, один из форматов представления реального приватного ключа. И он действительно содержит в себе служебную информацию: спереди добавляется идентификатор сети, сзади - контрольное число, производное от хэша ключа. Поскольку служебная информация добавляется к шестнадцатеричному представлению ключа, и лишь затем полученное значение конвертируется в Base58, невозможно точное вычленение служебной информации на уровне отсечения Base58-символов.
С идентификатором сети попроще. В исходном виде это - байт, приписываемый спереди, то есть ооооочень большое круглое шестнадцатричное число. В Base58 приписывание этого байта выглядит, как прибавление к исходному числу (приватный ключ) бОльшего числа с ничем не примечательным (некруглым) набором Base58 цифр. Однако на практике достаточно отсечь первый символ из base58 записи числа- пятерку. Остальные цифры представляют константу. Прибавление константы к случайному числу дает в итоге случайное число. Тут все в порядке. WIF-запись приватного ключа без пятерки - случайное число, можно гаммировать.
С контрольным числом в конце - сложнее. Хотя хэш от случайного числа сам по себе практически случаен и итоговый текст не имеет статистических особенностей, облегчающих его дешифровку - это именно то, чем оно является - контрольная информация. То есть, позволяет легко проверить, правильно ли дешифрован весь текст.
Отсюда мысль - либо использовать гамму, равную по длине всей WIF-записи, либо все-таки шифровать сам исходный ключ. Второе сложно осуествить ручным методом, а в качестве программного метода существует BIP38 - предложенный формат представления в зашифрованном виде.
Буду луркать дальше.