tonpie.io

Недавно обновление TON позволило пользователям отправлять транзакции с помощью сквозных зашифрованных текстовых сообщений. Правильно ли я понимаю, что шифрование происходит на стороне клиента и смарт-контракт кошелька в нем не задействован?

Этот вопрос был импортирован из чата Telegram: <***Скрыто***

click to show

Оригинал вопроса

Я хотел бы хранить данные в хранилище смарт-контрактов таким образом, чтобы только владелец этого смарт-контракта мог их прочитать. Как этого добиться?

Этот вопрос был импортирован из чата Telegram: <***Скрыто***

click to show

Оригинал вопроса

В JS-библиотеке ton-crypto есть функция mnemonicNew, я думаю, это то, что вы ищете: https://github.com/tonwhales/ton-crypto

Решено

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

Я должен также отметить, что можно сгенерировать закрытый ключ без использования мнемонической фразы. Обычно используемые кошельки обычно не предоставляют такую функциональность (потому что вы не сможете создать резервную копию своего кошелька, написав где-нибудь эту фразу), но теоретически это возможно. Это позволит снизить вероятность столкновения (из 1 в ≈ 20482⁴ 3⋅10⁷⁹ как вы правильно сказали, с 1 в ≈ 2⁵12 101⁵⁴), но не полностью ликвидировать ее. Поскольку кошельки генерируются независимо, реального способа предотвратить столкновение в теоретическом смысле не существует.

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

Теперь перейдем к вашим вопросам:

Чисто гипотетически – да, столкновения возможны. 2. Оценить точную скорость сложно, потому что это действительно зависит от аппаратного обеспечения. На моем компьютере бенчмарк vaniton показал скорость 13,7 адресов в секунду. Добавление большего количества серверов пропорционально увеличило бы скорость атаки методом перебора. Опять же, если мы говорим чисто теоретически, то нет ограничений на потенциальную скорость атаки (но на самом деле даже использование всех доступных на Земле вычислительных мощностей не сильно поможет). 3. Да, это верно.

Я хотел бы еще раз подчеркнуть: хотя все эти утверждения верны в теории, перебрать 3 из 10 фраз в любом практическом смысле невозможно (независимо от того, сколько серверов вы используете). Например, если бы у вас был доступ к 1 миллиарду серверов, каждому из них все равно нужно было бы проверить примерно 3⋅10⁷⁰ фраз, что по-прежнему является астрономически огромным числом. Даже если предположить, что скорость составляет 3 миллиона фраз в секунду (на каждом сервере), это займет 10⁶⁴ секунд или около 3⋅10⁵⁶ лет (это 56-значное число). Для сравнения, текущий возраст Вселенной составляет "всего" 1,37⋅10⁹ лет.

Решено

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

Проще говоря, вы можете обратиться к этому файлу TypeScript, чтобы понять, как мы можем сгенерировать адрес кошелька:

https://github.com/toncenter/tonweb-mnemonic/blob/master/src/functions/mnemonic-to-seed.ts

Как вы можете видеть, pbkdf2Sha512, по-видимому, представляет собой комбинацию PBKDF2 (функция получения ключа на основе пароля 2) и Sha512, оба из которых являются криптографическими методами.

Существует основной TON monorepo, который включает криптографию: https://github.com/ton-blockchain/ton

Есть также TON Connect. Насколько я понимаю, вместо этого TON monorepo он использует библиотеку NaCl для шифрования.

Правильно ли я понимаю, что в блокчейне TON существуют разные подходы к криптографии? Это почему?

Этот вопрос был импортирован из чата Telegram: <***Скрыто***

click to show

Оригинал вопроса

Решено

Чтобы лучше понять роль "CRC-32" в сети TON и его связь с "пакетом ячеек" (BOCs), важно сначала ознакомиться с концепцией циклической проверки избыточности (CRC) и ее основным назначением.

** CRC - это широко используемый метод проверки целостности цифровых данных.** ** В качестве алгоритма обнаружения ошибок ** он проверяет наличие ошибок в цифровых данных во время передачи или хранения.

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

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

**В сети TON CRC-32 используется в качестве компонента формата сериализации пакета ячеек (BOC) для обеспечения целостности данных. ** BOC - это двоичный формат, представляющий дерево ячеек, используемый для хранения и передачи данных в сети TON. Каждая ячейка в BOC содержит небольшой фрагмент данных и может содержать ссылки на другие ячейки.

Во время сериализации или десериализации BOC для данных ячейки вычисляется контрольная сумма CRC-32, чтобы гарантировать, что они не были повреждены во время передачи или хранения. Если вычисленная контрольная сумма CRC-32 не совпадает с суммой, сохраненной в BOC, это указывает на то, что данные повреждены и их необходимо повторно передать или извлечь.

Для получения дополнительной информации о CRC-32 и его использовании в сети TON обратитесь к следующим ресурсам:

TON Documentation on CRC-32: https://docs.ton.org/develop/data-formats/crc32 * Online CRC-16 Calculator: https://emn178.github.io/online-tools/crc16.html

Решено

Один из возможных способов получить адрес "кошелька V3r2" из адреса v4r2 - это вычислить его по открытому ключу.

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

Решено

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

В отрывке упоминаются два конкретных алгоритма эллиптической кривой, используемых в TON: Ed25519 и Curve25519.

Ed25519: Это алгоритм цифровой подписи с эллиптической кривой, который обеспечивает высокую безопасность, высокую производительность и компактные подписи. Он основан на скрученной кривой Эдвардса и был разработан Дэниелом Дж. Бернштейном, Нильсом Дуифом, Таней Ланге, Питером Швабе и Бо-Инь Янгом. В TON Ed25519 используется для создания криптографических подписей Шнорра, которые являются разновидностью схемы цифровой подписи.

Curve25519: Это эллиптическая кривая, разработанная для согласования ключей в криптографии с открытым ключом, в частности, в протоколе обмена ключами Elliptic Curve Диффи-Хеллмана (ECDH). Он также был разработан Дэниелом Дж. Бернштейном. Curve25519 используется для асимметричной криптографии в TON, обеспечивая безопасную связь между сторонами без необходимости предварительного получения общего секретного ключа.

Как Ed25519, так и Curve25519 используются стандартными способами в соответствии с их первоначальными спецификациями и соответствующими RFC (Запрос комментариев) 7748 и 8032. Однако у TON есть некоторые специфические детали сериализации и адаптации для удовлетворения своих уникальных требований.

Одной из таких адаптаций является автоматическое преобразование ключей Ed25519 в ключи Curve25519. Эта функция позволяет использовать одни и те же ключи как для цифровых подписей (через Ed25519), так и для асимметричной криптографии (через Curve25519). Это упрощает управление ключами и повышает общую эффективность криптографических операций TON.

Таким образом, TON использует криптографию с эллиптической кривой, используя алгоритмы Ed25519 и Curve25519 для цифровых подписей и асимметричной криптографии соответственно. Кроме того, TON поддерживает автоматическое преобразование ключей между двумя алгоритмами, оптимизируя криптографические операции внутри сети.

Решено

Да, любые случайно сгенерированные 256 бит могут быть использованы в качестве начального значения для генерации закрытого ключа Ed25519. Одним из возможных способов генерации закрытого ключа из такого начального значения является использование криптографической хэш-функции, такой как SHA256.

Решено

Для генерации закрытого ключа из seed pharse вы можете использовать эту библиотеку. Из mnemonic вы получите секретный (приватный) + открытый ключи

Это невозможно. Вы не можете получить начальную фразу из парных ключей.