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