Отправил вам письмо на яндекс почту с прикрепленным файлом анализа. Если нужно пришлем код, как доработаем. Если есть замечания/пожелания - пишите/звоните.
Мой техник пытается воспроизвести процесс. Пишет: "
Установлена чистая среда с Python 3.10 (через pyenv). Установил зависимости «как у автора» numpy==1.26.4 scipy==1.11.4 scikit-learn==1.3.2 pandas==2.1.4 networkx==3.1 matplotlib==3.7.4 sympy==1.12 tqdm==4.66.4 psutil==5.9.8 fastecdsa==2.3.0
No module named auditcore — в этом репо нет Python-пакета auditcore (нет setup.py/pyproject.toml и папки auditcore/). У автора это либо ставится как пакет из другой ветки/релиза, либо он запускает скрипты из каталога Scripts/. Поэтому python -m auditcore тут не взлетит.
дальше еще ошибка Ошибка: non-default argument 'execution_time' follows default argument. Значит, в дата-классах поле execution_time: float объявлено без дефолта, но перед ним уже есть поля с дефолтом. фиксим делаем с дефолтом.
дальше еще ошибка валится на ECDSASignature в аннотациях внутри signature_generator.py. Чиним это одной правкой — делаем форвард-ссылки (берём тип в кавычки), чтобы класс мог упоминаться до своего объявления.
дальше еще ошибка Теперь падает на Enum в betti_analyzer.py. Добавляем нужные импорты сразу во все модули, где они обычно требуются, и запускаем.
дальше снова ошибка Теперь Падает torch потому что в этом чистом окружении нет PyTorch, а TCON.py его импортит. Ставим CPU-версию PyTorch для Python 3.10
опять ошибка ошибка non-default argument 'execution_time' follows default argument → в collision_engine.py (и паре модулей) полям execution_time/description надо дать дефолты;
дальше снова упало auditcore.py есть class Point(Protocol), а дальше конструктор Point(...) — это и даёт Protocols cannot be instantiated. Починим алиасом: реальную точку из fastecdsa назовём ECPointReal, а все вызовы конструктора переведём на неё. Типовой Point для аннотаций трогать не будем.
Вы писали что ваша система: Multi-platform: CPU, GPU, and distributed computing support via DynamicComputeRouter. Есть скромные мощности в виде 64 видеокарт GeForce RTX 3080 Ti и 144Tb Sata 3, если нужно можно попробовать подключить к вашей системе.
До того как нашел вашу статью не оставляла мысль, что что обязательно должны существовать зависимости, связанные с геометрией эллиптической кривой secp256k1, свойствами простого конечного поля и циклической природой модульной матаматики. В десятках статей были описаны различные подходы к поиску уязвимостей, в основном эксплуатирующие "человеческий фактор", некорректные RNG либо утечки данных. Методы работы с подгруппами, образованными делителями порядка группы тоже считал перспективными, как и рекурсивные методы flatter, где понижается базис решетки без нарушения ее структуры, что схоже с вашими спиральными фракталами. однако их природа больше эмпирическая или вероятностная. Ваш подход ограничивает расположение подписей и их свойства принадлежностью поверхности тора и дает новые возможности анализа безопасности, однако необходимо изучить десятки новых понятий и разобраться в их практической применимости, что довольно сложно.
Полностью разделяем ваши этические принципы в отношении частной собственности на цифровые активы, ведь существует множество способов заработать не переступая черту: биткоин паззл, утерянные активы, анализ безопасности и т.д.
Впечатляет как сама идея, так и объем проделанной работы. По классике хорошо бы теорию подкрепить практикой например как у Нади: (https://eprint.iacr.org/2019/023.pdf) на определенных мощностях и с временной оценкой (желательно менее 10 тыс. лет). "After running our attacks, we had computed the private keys for 302 distinct keys that were compromised via small nonces, nonces with shared prefixes, or nonces with shared suffixes. These keys had generated 6,026 signatures with these vulnerable nonces in the blockchain, and 7,328 signatures overall, including signatures that we did not classify as using vulnerable nonces. We implemented these tests in Sage [36], using the built-in BKZ implementation for lattice basis reduction. We ran the computation parallelized across 2000 cores of a heterogeneous cluster with mostly Intel Xeon E5 processors. For the low-dimensional lattice attacks, the bottleneck of the computation was the elliptic curve multiplications required to check whether we had found the correct private key. The total running time for both jobs was 38 CPU years, and the longest-running job (corresponding to a single key that had generated 1,021,572 signatures in March 2018) completed in 30 calendar days.
Если все возможные сигнатуры для данного ключа существуют в таблице как элементы тора, то каков порядок этой подгруппы для secp256k1? Достижимо ли при обнаружении уязвимости вычисление приватного ключа за полиномиальное время? Подобный метод с визуализацией сокращения базиса решетки представлен в алгоритме flatter: https://github.com/keeganryan/flatter. Там же есть визуализация снижения базиса решетки. Visualization: We include a tool for visualizing the evolution of the profile during execution of our lattice reduction algorithm. https://eprint.iacr.org/2023/237.pdf
Интересный метод, визуализация - мощный аналитический инструмент! Восстановление приватного ключа из повторяющихся k-nonce задача давно решенная, а вот определение типа потенциальной уязвимости, а так же создание инструмента ECDSA-Torus для анализа публичных ключей - перспективно. Однако ее следует рассматривать относительно применения существующих алгоритмов решеток, LLL, BKZ 2.0, BSGS и доступных вычислительных мощностей для оценки практического времени их выполнения. Так же важно практическое применение в отношении реальных кошельков Bitcoin и Ethereum и реальных подписей, а не сгенеренных "специально под задачу".
Была ошибка в адресе почты, все написал в письме, файл с анализом прикрепил.
Отправил вам письмо на яндекс почту с прикрепленным файлом анализа. Если нужно пришлем код, как доработаем. Если есть замечания/пожелания - пишите/звоните.
Мой техник пытается воспроизвести процесс. Пишет: "
Установлена чистая среда с Python 3.10 (через pyenv).
Установил зависимости «как у автора»
numpy==1.26.4
scipy==1.11.4
scikit-learn==1.3.2
pandas==2.1.4
networkx==3.1
matplotlib==3.7.4
sympy==1.12
tqdm==4.66.4
psutil==5.9.8
fastecdsa==2.3.0
TDA-часть (работает на Py3.10 + NumPy 1.26)
ripser==0.6.8
persim==0.3.8
umap-learn==0.5.6
kmapper==2.0.1
при запуске ошибка.
No module named auditcore — в этом репо нет Python-пакета auditcore (нет setup.py/pyproject.toml и папки auditcore/). У автора это либо ставится как пакет из другой ветки/релиза, либо он запускает скрипты из каталога Scripts/. Поэтому python -m auditcore тут не взлетит.
дальше еще ошибка
Ошибка: non-default argument 'execution_time' follows default argument. Значит, в дата-классах поле execution_time: float объявлено без дефолта, но перед ним уже есть поля с дефолтом. фиксим делаем с дефолтом.
дальше еще ошибка
валится на ECDSASignature в аннотациях внутри signature_generator.py. Чиним это одной правкой — делаем форвард-ссылки (берём тип в кавычки), чтобы класс мог упоминаться до своего объявления.
дальше еще ошибка
Теперь падает на Enum в betti_analyzer.py. Добавляем нужные импорты сразу во все модули, где они обычно требуются, и запускаем.
дальше снова ошибка
Теперь Падает torch потому что в этом чистом окружении нет PyTorch, а TCON.py его импортит. Ставим CPU-версию PyTorch для Python 3.10
опять ошибка
ошибка non-default argument 'execution_time' follows default argument → в collision_engine.py (и паре модулей) полям execution_time/description надо дать дефолты;
дальше снова упало
auditcore.py есть class Point(Protocol), а дальше конструктор Point(...) — это и даёт Protocols cannot be instantiated. Починим алиасом: реальную точку из fastecdsa назовём ECPointReal, а все вызовы конструктора переведём на неё. Типовой Point для аннотаций трогать не будем.
бесконечный рулон ошибок одна хуже другой."
Вы писали что ваша система: Multi-platform: CPU, GPU, and distributed computing support via DynamicComputeRouter. Есть скромные мощности в виде 64 видеокарт GeForce RTX 3080 Ti и 144Tb Sata 3, если нужно можно попробовать подключить к вашей системе.
До того как нашел вашу статью не оставляла мысль, что что обязательно должны существовать зависимости, связанные с геометрией эллиптической кривой secp256k1, свойствами простого конечного поля и циклической природой модульной матаматики. В десятках статей были описаны различные подходы к поиску уязвимостей, в основном эксплуатирующие "человеческий фактор", некорректные RNG либо утечки данных. Методы работы с подгруппами, образованными делителями порядка группы тоже считал перспективными, как и рекурсивные методы flatter, где понижается базис решетки без нарушения ее структуры, что схоже с вашими спиральными фракталами. однако их природа больше эмпирическая или вероятностная. Ваш подход ограничивает расположение подписей и их свойства принадлежностью поверхности тора и дает новые возможности анализа безопасности, однако необходимо изучить десятки новых понятий и разобраться в их практической применимости, что довольно сложно.
Полностью разделяем ваши этические принципы в отношении частной собственности на цифровые активы, ведь существует множество способов заработать не переступая черту: биткоин паззл, утерянные активы, анализ безопасности и т.д.
Впечатляет как сама идея, так и объем проделанной работы. По классике хорошо бы теорию подкрепить практикой например как у Нади: (https://eprint.iacr.org/2019/023.pdf) на определенных мощностях и с временной оценкой (желательно менее 10 тыс. лет). "After running our attacks, we had computed the private keys for 302 distinct keys that were compromised via small nonces, nonces with shared prefixes, or nonces with shared suffixes. These keys had generated 6,026 signatures with these vulnerable nonces in the blockchain, and 7,328 signatures overall, including signatures that we did not classify as using vulnerable nonces. We implemented these tests in Sage [36], using the built-in BKZ implementation for lattice basis reduction. We ran the computation parallelized across 2000 cores of a heterogeneous cluster with mostly Intel Xeon E5 processors. For the low-dimensional lattice attacks, the bottleneck of the computation was the elliptic curve multiplications required to check whether we had found the correct private key. The total running time for both jobs was 38 CPU years, and the longest-running job (corresponding to a single key that had generated 1,021,572 signatures in March 2018) completed in 30 calendar days.
Если все возможные сигнатуры для данного ключа существуют в таблице
как элементы тора, то каков порядок этой подгруппы для secp256k1? Достижимо ли при обнаружении уязвимости вычисление приватного ключа за полиномиальное время? Подобный метод с визуализацией сокращения базиса решетки представлен в алгоритме flatter: https://github.com/keeganryan/flatter. Там же есть визуализация снижения базиса решетки. Visualization: We include a tool for visualizing the evolution of the profile during execution of our lattice reduction algorithm. https://eprint.iacr.org/2023/237.pdf
Интересный метод, визуализация - мощный аналитический инструмент! Восстановление приватного ключа из повторяющихся k-nonce задача давно решенная, а вот определение типа потенциальной уязвимости, а так же создание инструмента ECDSA-Torus для анализа публичных ключей - перспективно. Однако ее следует рассматривать относительно применения существующих алгоритмов решеток, LLL, BKZ 2.0, BSGS и доступных вычислительных мощностей для оценки практического времени их выполнения. Так же важно практическое применение в отношении реальных кошельков Bitcoin и Ethereum и реальных подписей, а не сгенеренных "специально под задачу".