Topic: Хранение SEED фразы кошелька - page 2. (Read 4920 times)

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

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

1  слово seed - это просто 1 такая цифра в base2048

2  ключи генеряться из seed (и много, всяких и разных!) - после 2000 циклов SHA


То есть каждое слово - тупо 11 бит, тут бит-в-бит ложиться, в отличии от "неровных" оснований где надо пересчитывать делением и остатками...

Подождите. Мнемоническая фраза является человекочитаемым представлением энтропии, это так. Но она же и получена из энтропии. И именно она, а не энтропия, является источником дальнейших преобразований.
Благодарю, ошибку понял - не учел, что на входе программа ждет текст, а не hex. Сделал то же в https://cryptii.com/pipes/aes-encryption , и там получил с cbc и ctr 48 и 32 байта соответственно.

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


Ты на вход подаёшь 64 байта, а нужно 32. Base64 занимает больше байтов, чем сырой поток.

Я и сам не знаю, что правильно тут называть сидом ). Кто-то сидом называет энтропию, кто-то мнемоническую фразу, полученную из этой энтропии, а кто-то 512-битное число, полученное из этой фразы с паролем (как в https://iancoleman.io/bip39/). Первое и второе - по сути одно и то же, просто по-разному представлено.
1. Ввёл c031d297ed241cdd12cf59adbe594a52ba7c56a632565a6bb0d45ca1f76b9c00
2. Сделал
3. Ввел 12345678123456781234567812345678
4. Сделал
5. Получил E504167E48EBD149B27B85D94AD4F332260940C65A6C112D1D2CBE3EC5F61FA3234CE7F21703648 D8D6340557001B2A12383013A4FA4254F15A437E050AAB6D805CCFA77A2AFE33962768C20800CF0 6D

80 байт, в Base64 - 64 байта (не понял вашего "даже") Где ошибка? Могу скрин сделать.

Новички как раз уверены что сид это не число, а эти слова и с такой подачей они и дальше будут в этом заблуждаться.


Ты точно ничего не упустил?
1. Вводишь 32-байтный текст который хочешь зашифровать
2. Выбираешь режим CBC и размер ключа 256 бит
3. Вводишь 32-байтный секретный ключ
4. Выбираешь вывод в формате hex
5. Получаешь 96 символьный hex

Что ты сделал с полученным hex что у тебя получилось 80 байт? Он даже в base64 занимает 64 байта.


Софт не подскажу. Подозреваю что openssl делает что-то что тебе не требуется, например объединяет ключ с данными, чтобы можно было сверять правильность ключа. Тебе нужно сверять правильность или оставишь злоумышленников без подсказок?

ну зашибись, чо!..




а, уже начинаете подозревать, да?    Ну это уже хорошо - хоть какой-то прогресс...

А Вы уверены, что Ваш AES скажем на 125-м цикле не расшировывает данные обратно?..
(там же просто всякие там перестановки и сдвиги - если сильно хорошо подвигать, то может и обратно вернуться!)


Причем это хорошо если просто расшифровывает - в этом случае можно написать тест и проверить...

А если не 1:1 расшифровывает, а скажем на 125-м цикле получаются те-же входные данные, просто сдвинутые на 1 бит по кругу и умноженные на 5?


Тогда ваши 1000 циклов не просто ускоряются, но и сломаются совсем - простой обратной функцией типа 8 раз разделить на 5, и сдвинуть по кругу в обратном направлении...


PS  наш аналитик рассказывал вам про пароли в каком-то архиваторе?   Очень поучительно!..

Может, вы и правы, но, по-моему, со словами проще для новичков.
Попробовал, получил 80 байт ).
Каким софтом пользоваться для этого? В openssl aes-256-ctr из 32 байт получается 64. Но это все равно прогресс, спасибо. Только надо почитать, не страдает ли надежность.

Вот вы привязались к 80 байтам ((
Никто не обратил внимания на мою статью на хабре почему-то Запись и чтение данных в блокчейне биткоина

Информация про слова здесь в любом случае лишняя и запутывает даже не новичков, поэтому не стоило её изначально упоминать. Я не учёл особенности openssl и cbc, но всё равно 80 байт это больше чем нужно. Openssl использует избыточное кодирование. На самом деле aes-256-cbc помещается в 64 байта. Можешь в этом убедиться выбрав hex - https://www.devglan.com/online-tools/aes-encryption-decryption

Если вместо cbc использовать ctr, то шифрованый 32-байтный сид поместится в 32 байта. Насколько это надёжно не подскажу, но надёжность определённо можно повысить не увеличивая размер данных.


Теплоухов, прекращай безобразничать и бегом на процедуры, а после в столовку за котлетками с пюрешкой

что не понятного?   Вроде уже все разжевали...

А ваши миллионы циклов вообще никак не помогут - потому что любой нормальный хакер будет перебирать не ваши пароли(это только психологам может быть интересно, но пока таких полных моделей мозга еще не существует) - а просто ГОТОВЫЕ коды, которые у вас получаются на выходе только после миллионов циклов...

Уверены, что коды на выходе _криптостойкой_ функции распределены равномерно, и нельзя увеличить вероятность нахождения в разы, например перебирая только четные или нечетные(или еще по какой-то функции - там сперва надо на аналитическом пакеты все эти формулы SHA прогонять - не исключено что после многих циклов часто бывает какие-то члены уравнения просто сокращаются!) коды?..


То есть то что вы думаете что повышает стойкость - на самом деле создает проблемы только вам, а стойкость может наоборот снижаться!


а кто считал число перестановок слов сида?   Ну типа 12! и 24!...

Вот это крутая идея, да!..

Толкового разговора у нас не получится, я вижу. Ну и ладно.

Не было у меня такой идеи. Вы меня, видимо, с кем-то спутали.

))
ну ппц вы нас тут весилите не слабо...

Вы не гуманитарий, случайно?..

Так вроде на вид совсем не чайник, но иногда такие штуки выкидываете, что просто диву даешься... 
(хотя хз, может это просто разница в подходах старого хакера...  Кстати, как у вас с хаком, с дизассемблерами и тп дружите?.. )


В данном случае - это как раз САМЫЙ криптостойкий вариант - _даже если использовать для хэширования СОВСЕМ не криптостойкую функцию_!    Хоть готовую теорему объяснить сможете?..



PS  подскажу еще:  криптостойкость и _равномерность распределения_ - это совсем разные параметры!..
И если использовать не стойкую, но _равномерную_ функцию - то тут ппц ваше не взломаешь - поскольку именно этот самый XOR с со случайным ключом и обеспечит уже высокую криптостойкость!   Равномерность более равномерна у специальных хэширующих функций - они могут быть не стойкие, но равномерные - в этом случае никакие танцы с бубном никак не позволяют ускорить перебор!..
А вот в вашем случае AES даже если считать криптостойким(в чем кстати некоторые криптологи сомневаются) - то никакой гарантии что после многих циклов он будет иметь _равномерное_ распределение нет!!!  Понимаете идею?..
То есть возможно что будет найден алгоритм ускоренного перебора - будут перебирать только те диапазоны кодов, где вероятность выше, _причем миллионы циклов хэширования никто крутить не будет_ тк это просто не нужно, проще перебирать уже НА УРОВНЕ ГОТОВОГО КОДА, что _очень быстро_!!!    Сюрприз?..


PPS  да, вот насчет факториала у вас была классная идея!   Это стоит обдумать!!    Возможно даже новые особо стойкие методы удастся изобрести - не хотите поработать с математиками (потом получим патенты)?..
(с факториалом шикарно то, что таблица кодов, из которых делается комбинация - может быть вообще открытой!!!
А это как раз дает возможность использовать действительно ДЛИННЫЕ и _по-настоящему случайные_ коды!!!
Понятна идея?   То есть счас у вас проблема запоминания больших данных - а тут длины ключей могут быть на порядки больше...)

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

А зачем AES, да ещё и много циклов?

Просто SHA(Pass) XOR KEY  -- причем SHA любой, хоть 1й, хоть MD5 - Вы понимаете, что криптостойкость _в данном_ случае не требуется, или нет?..

А чем _данный_ случай отличается от прочих? Если наличием passphrase, то по такой логике можно вообще не шифровать. Мало ли что могут эти 32 байта содержать, может это хеш какого-то документа, договора какого-нибудь...

не факт что сложные методы _в данном_ случае окажуться надежнее самого приметивного XOR...

Я шифровал не слова, а именно эти 32 байта openssl aes-256-cbc, на выходе получалось 80 байт, причем специально шифровал без соли, иначе было бы 96 байт. Если вам известно, как получить надежную шифровку более компактной, то поделитесь методом.

Что такое энтропия сида из 24 слов и почему она не помещается в 80 байт? Причём здесь вообще слова? 24 слова это всего лишь человекочитаемый способ отображения сида, то есть большого числа. Число 256-битное, то есть 32-байтное. Зачем записывать в блокчейн число именно в человекочитаемом виде, если на выходе всё то же 32-байтное число?