С приходом ИИ человек рано или поздно разучиться думать. Куда проще спросить нейросеть, чем лезть курить мануалы, смотреть сниппеты кода, разбираться в RFC. Но человек получает сиюминутный ответ, попутно теряя ту информацию, которую нарыл бы в процессе разбора бага или кривых настроек.
На такой легкий и простой "успех" человек легко подсаживается и слезть с этой иглы бывает крайне сложно. Человек постепенно разучается думать, анализировать, рассуждать.
С течением времени появятся кнопкодавы операторы ИИ и люди, на ком будет все держаться. Это неизбежно практически.
Ну про «успешный успех», молодежь сейчас учат формировать «личный бренд» и беречь честь с молоду и все такое, но для их будущих менторов, наставников, тим-лидов и прочих, такой кейс может быть не совсем понятен и корректно принят в последствии.
В самом участии в хакатонах, митапах и прочем вот вообще ничего плохого нет, но этакий «плохо» пахнущий ивент плюсом к карме не будет. Даже если за время его проведения студенты и улучшили свои навыки в чем-то. Да и приятнее писать то, чем будешь пользоваться в дальнейшем. А у кого-то из них этот «госмессенджер» установлен?:)
А я вот прочитал внимательно:) Ты в команде git clone забыл свой репо указать. У тебя ссылка от AI осталась, который этот бот или писал или статью для тебя писал:)
Я не математик, я практик с небольшой подготовкой в криптографии (https://github.com/Dookoo2) потому могу задавать глуповатые вопросы для подготовленного человека. Но если это так как написано в статье, то, блин, это прорыв на самом деле. Я попробую алгоритмически описать ваши наблюдения и протестировать.
Ну-ка поясни, я как-то про это не думал. То есть даже при абсолютно рандомных K мы можем найти закономерности на графике, которые могут ограничить поиск закрытого ключа не всем порядком кривой, а только ее части?
Иногда не случайно, если например ГПСЧ тупит и кластеризует K из-за хреновой энтропии, например, или вообще переиспользует K для подписец. Тогда на подобном графике можно увидеть «облако» или явные точки на одной линии и уже бить более целенаправлено например через LLL алгоритм.
Но при текущей реализации ECDSA в нормальных библиотеках это крайне маловероятно. Статья просто как информация, практической ценности не несет.
При копировании данных с GPU с хоста, в какую памчть трамбовал данные? Shared/global?
Была ли задействована constant память для каких-то данных?
Сколько потоков запускал?
Тестил ли на register pressure наборы данных, чтобы gpu не подтормаживала?
Вижу вывод с винды, GPU немного недозагружена, но возможно это кривое отображение задействованных ресурсов GPU, так все-таки, пробовал ли на 100% ее загрузить?
Считалось на CUDA или тензоры тоже подключались для каких-то действий?
на самом деле не так сложно как кажется! Да, я не программист, за деньги в своей жизни ни строчки кода не написал, но в целом в IT человек не случайный.
Серию статей напишу, как только найду в себе силы, тут есть чем поделиться. Последние недели я писал свой распределенный пул для брутфорса головоломки сатоши на GPU. И он уже работает.
А вообще история пула за свою трехнедельную историю почти как детектив с кибератаками, противодействием, переговорами с китами аппаратных мощностей, падение, запуски снова, скорость в пике до 24 Теркалючей в секунду (5090 до 8.5Gkeys/s дает).
Нормальный бы программист столько косяков не собрал, как я самоучка:)
Я немного знаю автора, вполне вменяемый и уважаемый в сообществе человек. Так что гайду можно верить, но делать строго как там написано. Написано отключить инет - отключай.
Господи, какой ужас… Курсы программирования в Видном, похожи на курсы программирования в Химках, только курсы программирования в Видном, ряжом с баром БарДак, пивнухой и общагой для гастеров. Наши курсы программирования в Видном, самые лучшие курсы программирования в Видном!
Есть 2 подхода для проектирования NGFW и обработки данных на нем, применительно к вычислительным мощностям:
CPU only - путь CheckPoint. За счет AVX/SSE/MBMI и прочих интринсиков батчить пакеты в регистрах CPU для параллельной обработки + низкоуровневые оптимизации драйверов и движков обработки данных с ASM внутри.
FPGA (ПЛИС)/ASIC - спец чипы для обработки той или иной операции.
Нигде в РФ я не видел хотя бы FPGA для какой-то из функций сетевой железки, все рубят в CPU и потому такая хреновая производительность.
А все почему, FPGA дороги? Нет! Просто нет вменяемых людей, кто может нормально спроектировать FPGA конвейер и отсинтезировать его работу. Формы на WebUI нашлепать - легко, взять opensource пакеты с перелицовкой якобы под бренд - еще проще. Затянуть к себе в "движки" SNORT/SURICATA/BRO - подержите мое пиво.
А лезть внутрь, нахер недо, в opensource этого ведь нет.
Короче начинание хорошее, еще один недоNGFW в России наравне с Континент, UserGate и прочим. Года 3-4 и может что и выйдет вменяемого.
P.S. Вру, видел я FPGA в РФ, в коммутаторах ELTEX.
На эллиптических кривых в конечном поле нет как такового деления точек, есть умножение на мультипликативное обратное, что эквивалентно делению. Так как кривая циклична, то деление произвольной точки на мультипликативное обратное 2 может дать как открытый ключ, чей скаляр в 2 раза меньше исходного, так и вынести получившуюся точку далеко от изначальной, если изначальный открытый ключ соответствовал нечетному скаляру.
Алгоритм Shanks BSGS дает сложность Sqrt(b-a) только при условии сохранения память количества точек равную Sqrt(b-a), что для диапазонов типа 2^120 или не дай бог 2^256 обречено на провал. В случае сохранения в память произвольного количества точек Z, мы получим формулу O(N/Z), где N - порядок кривой или тот диапазон в котором осуществляется поиск. Для больших диапазонов лучше использовать Pollard Lambda/Pollard Rho.
Я уже пол-года как пилю брутфорсеры для BTC головоломки сатоши, перепробовал многое, в том числе и нечто похожее, что ты описал в статье, детская поделка. Коллектим миллиард точек в память и значения их скаляра. После чего открытый ключ, чей скаляр мы ищем, умножаем на производное мультипликативное обратное, если частное (точнее открытый ключ) получившийся в результате "деления" присутствует в массиве сохраненных точек, мы восстанавливаем значение скаляра от известного открытого ключа. Чтобы ненароком не пытаться делить искомый открытый ключ, чей скаляр - простое число или имеет мало делителей, каждый N кусок времени мы вычитаем из открытого ключа произвольное число равное 5% от диапазона поиска и накапливаем оффсет. После чего делим уже новый открытый ключ, получившийся в результате сужения диапазона. Но так можно делить до второго пришествия:)
Также недавно запилил брутфорсер на CUDA, вполне возможно, что с рекордной скоростью в 6.2 Gkeys/s на RTX4090 (результаты достигнуты, есть скрины), но столкнулся с проблемой с железом. После 1.5 часа работы горячая GDDR6X "начинает кипеть" и сбрасывать частоту памяти, что сносит скорость до 4.9 Gkeys/s. Я как GPU майнер, при холодном ядре кипящие и визжащие банки памяти. Сейчас пытаюсь это победить. Silicon lottery в чистом виде. Вот ссылки на проекты: https://github.com/Dookoo2
Нет конечно, я свой софт вообще нигде не презентовал, только на Bitcointalk. Это ведь не index calculus для Secp256k1, не найденная изогения или какой-то необычный эндоморфизм, и не успешное решение полиномов Семаева для ECDLP.
Допустим 1 поток, в потоке 256 кенгуру, поток делает 5 миллионов прыжков в секунду, каждый кенгуру проскачет X прыжков. Сменим на 32 кенгуру, за тоже время каждый кенгуру проскачет 8x прыжков. Кажется, что разницы практически нет, но она есть и это факт. При бОльшем количестве прыжков в секунду на 1 кенгуру решение находится быстрее. Если поставить меньше кенгуру в потоке, то уже играет модульная инверсия, она жрет под 50% тактов для сложения точек и скорость резко падает. При 32 кенгурухах в потоке скорость стандартная, без падений.
Мой Mark1 работает не совсем как классический вариант. Я сначала стартую tame kang, точки старта выбираются как диапазон/количество потоков. В каждом поддиапазоне стартуют 32 кенгуру с известным смещением от точки старта. Если они допрыгивают до конца поддиапазона, срабатывает механизм wrap и кенгуруху возвращают обратно в поддиапазон, при этом накапливая оффсет сиещения от точки старта. При прыжках коллектятся DP, сохраняются только уникальные точки.
Далее стартуют wild кенгуру в поддиапазонах также по 32 в поддиапазоне, точно также прыгают и как только напрыгают размер диапазона wrap возвращает ее обратно в поддиапазон. Ни одного прыжка вне диапазона поиска не происходит. Работает детектор циклов Brent, ведь прыжки детерминированы и если одна кенгуруха уже была на какой-то точке, то другая кенгуруха посетив туже точку будет прыгать точно как предыдущая, тем самым снизив нам количество возможных траекторий.
Так что тут особой магии нет, почти классика, но именно что почти.
AI пользовался, как без этого, но честно сказать даже самые мощные модели типа o3, доступные на тот момент, просто жесть как тупили. Но если точечно попросить что-то добавить или подсказать, то норм. С нуля брутфорсер не напишут 100% или времени затратишь x5 от чисто самописного кода.
По CUDA все еще хуже, на самом деле, так что тут больше сам, благо мануалов и примеров много. Радует то, что множество операций типа point mult можно сделать на хосте и потом передать подготовленные данные на GPU, а сам GPU выполняет только point add, никаких point mult или hash160 делать не надо, просто вынести самый горячий цикл на cuda + закинуть bloom в vram.
Я взял в среднем по 32 кенгуру на поток при 32 потоках. брать больше - снижать количество прыжков каждого кенгуру на единицу времени и чаще попадать в циклы. Брать меньше - уже плохо работает батчевая инверсия и не достигается нужная скорость. Ч разбил алгоритм на 2 фазы - сначала все ручные коллектят DP, потом фаза 2 - дикие прыгают и ищут DP. При условии сохранения таблицы DP ч готов заплатить 1 раз много времени чтобы сколлектить DP, но потом их переиспользовать при возможных последующих запусках. Сами прыжки детерминированы, одинаковый Seed ГСЧ при всех запусках, как и таблицы прыжков. Так что у меня в параллель дикие и домашние не скачут. При параллельном запуске это просто баланс 1 к 1, например дает уполовинивание скорости GPU так как дикие кенгурушки не коллектят DP, 1 к 3 чуть получше, DP попадаются реже, но сами дикие кенгуру скачут быстрее. Так что я не стал морочиться и разбил просто на 2 фазы. При моих тестах сочетание 32 потока по 32 кенгуру дают лучшее время до нахождения коллизии. В коде Mark1.cpp это константы K и K_DP их можно поменять и поиграть с составом кенгурух.
На моей тестовой GPU реализации совсем по другому, чтобы загрузить все SM по 128 CUDA ядер в каждом(RTX 4060) мне надо много кенгурух запускать в параллель, много это около 140.000, по 64 где-то кенгурухи на поток, а тысячи потоков.
Я конечно рад за них, но не от всего сердца
О! Мотор колесо Дуюнова на новый лад. Слишком много недосказанностей, отсутствие фактов. Короче куда деньги слать?
С приходом ИИ человек рано или поздно разучиться думать. Куда проще спросить нейросеть, чем лезть курить мануалы, смотреть сниппеты кода, разбираться в RFC. Но человек получает сиюминутный ответ, попутно теряя ту информацию, которую нарыл бы в процессе разбора бага или кривых настроек.
На такой легкий и простой "успех" человек легко подсаживается и слезть с этой иглы бывает крайне сложно. Человек постепенно разучается думать, анализировать, рассуждать.
С течением времени появятся кнопкодавы операторы ИИ и люди, на ком будет все держаться. Это неизбежно практически.
Ну про «успешный успех», молодежь сейчас учат формировать «личный бренд» и беречь честь с молоду и все такое, но для их будущих менторов, наставников, тим-лидов и прочих, такой кейс может быть не совсем понятен и корректно принят в последствии.
В самом участии в хакатонах, митапах и прочем вот вообще ничего плохого нет, но этакий «плохо» пахнущий ивент плюсом к карме не будет. Даже если за время его проведения студенты и улучшили свои навыки в чем-то. Да и приятнее писать то, чем будешь пользоваться в дальнейшем. А у кого-то из них этот «госмессенджер» установлен?:)
А я вот прочитал внимательно:) Ты в команде git clone забыл свой репо указать. У тебя ссылка от AI осталась, который этот бот или писал или статью для тебя писал:)
Я так понял бедных парней и девушек под страхом «параши» в зачетке туда загоняли? Другого почснения придумать не могу.
Ты описал не эллиптическую кривую, а рациональную кривую, которая изморфна аддитивной или мультипликативной форме поля.
А твой секрет лишь доказывает, что это это вообще не эллиптическая кривая.
Так что обладатели биткоин кошельков пока что могут спать спокойно, пока что.
Я не математик, я практик с небольшой подготовкой в криптографии (https://github.com/Dookoo2) потому могу задавать глуповатые вопросы для подготовленного человека. Но если это так как написано в статье, то, блин, это прорыв на самом деле. Я попробую алгоритмически описать ваши наблюдения и протестировать.
Ну-ка поясни, я как-то про это не думал. То есть даже при абсолютно рандомных K мы можем найти закономерности на графике, которые могут ограничить поиск закрытого ключа не всем порядком кривой, а только ее части?
Иногда не случайно, если например ГПСЧ тупит и кластеризует K из-за хреновой энтропии, например, или вообще переиспользует K для подписец. Тогда на подобном графике можно увидеть «облако» или явные точки на одной линии и уже бить более целенаправлено например через LLL алгоритм.
Но при текущей реализации ECDSA в нормальных библиотеках это крайне маловероятно. Статья просто как информация, практической ценности не несет.
Мне интересно! Выкладывай:)
Можешь рассказать по следубщим пунктам:
Как синхронизировал батчи по варпам?
При копировании данных с GPU с хоста, в какую памчть трамбовал данные? Shared/global?
Была ли задействована constant память для каких-то данных?
Сколько потоков запускал?
Тестил ли на register pressure наборы данных, чтобы gpu не подтормаживала?
Вижу вывод с винды, GPU немного недозагружена, но возможно это кривое отображение задействованных ресурсов GPU, так все-таки, пробовал ли на 100% ее загрузить?
Считалось на CUDA или тензоры тоже подключались для каких-то действий?
Не упирался в троттлинг по памяти/кристаллу?
Спасибо за ответы заранее:)
на самом деле не так сложно как кажется! Да, я не программист, за деньги в своей жизни ни строчки кода не написал, но в целом в IT человек не случайный.
Серию статей напишу, как только найду в себе силы, тут есть чем поделиться. Последние недели я писал свой распределенный пул для брутфорса головоломки сатоши на GPU. И он уже работает.
Вот ссылка, подключайтесь. По сути лотерейка, но с шансами на успех, цена победы 800.000 долларов: https://github.com/Dookoo2/Distibuted-CUDACyclone
А вообще история пула за свою трехнедельную историю почти как детектив с кибератаками, противодействием, переговорами с китами аппаратных мощностей, падение, запуски снова, скорость в пике до 24 Теркалючей в секунду (5090 до 8.5Gkeys/s дает).
Нормальный бы программист столько косяков не собрал, как я самоучка:)
Но вроде все в прошлом, работаем стабильно
Я немного знаю автора, вполне вменяемый и уважаемый в сообществе человек. Так что гайду можно верить, но делать строго как там написано. Написано отключить инет - отключай.
Господи, какой ужас… Курсы программирования в Видном, похожи на курсы программирования в Химках, только курсы программирования в Видном, ряжом с баром БарДак, пивнухой и общагой для гастеров. Наши курсы программирования в Видном, самые лучшие курсы программирования в Видном!
Есть 2 подхода для проектирования NGFW и обработки данных на нем, применительно к вычислительным мощностям:
CPU only - путь CheckPoint. За счет AVX/SSE/MBMI и прочих интринсиков батчить пакеты в регистрах CPU для параллельной обработки + низкоуровневые оптимизации драйверов и движков обработки данных с ASM внутри.
FPGA (ПЛИС)/ASIC - спец чипы для обработки той или иной операции.
Нигде в РФ я не видел хотя бы FPGA для какой-то из функций сетевой железки, все рубят в CPU и потому такая хреновая производительность.
А все почему, FPGA дороги? Нет! Просто нет вменяемых людей, кто может нормально спроектировать FPGA конвейер и отсинтезировать его работу. Формы на WebUI нашлепать - легко, взять opensource пакеты с перелицовкой якобы под бренд - еще проще. Затянуть к себе в "движки" SNORT/SURICATA/BRO - подержите мое пиво.
А лезть внутрь, нахер недо, в opensource этого ведь нет.
Короче начинание хорошее, еще один недоNGFW в России наравне с Континент, UserGate и прочим. Года 3-4 и может что и выйдет вменяемого.
P.S. Вру, видел я FPGA в РФ, в коммутаторах ELTEX.
Шалом, господа! Можно внесу пару корректив?
На эллиптических кривых в конечном поле нет как такового деления точек, есть умножение на мультипликативное обратное, что эквивалентно делению. Так как кривая циклична, то деление произвольной точки на мультипликативное обратное 2 может дать как открытый ключ, чей скаляр в 2 раза меньше исходного, так и вынести получившуюся точку далеко от изначальной, если изначальный открытый ключ соответствовал нечетному скаляру.
Алгоритм Shanks BSGS дает сложность Sqrt(b-a) только при условии сохранения память количества точек равную Sqrt(b-a), что для диапазонов типа 2^120 или не дай бог 2^256 обречено на провал. В случае сохранения в память произвольного количества точек Z, мы получим формулу O(N/Z), где N - порядок кривой или тот диапазон в котором осуществляется поиск. Для больших диапазонов лучше использовать Pollard Lambda/Pollard Rho.
Я уже пол-года как пилю брутфорсеры для BTC головоломки сатоши, перепробовал многое, в том числе и нечто похожее, что ты описал в статье, детская поделка. Коллектим миллиард точек в память и значения их скаляра. После чего открытый ключ, чей скаляр мы ищем, умножаем на производное мультипликативное обратное, если частное (точнее открытый ключ) получившийся в результате "деления" присутствует в массиве сохраненных точек, мы восстанавливаем значение скаляра от известного открытого ключа. Чтобы ненароком не пытаться делить искомый открытый ключ, чей скаляр - простое число или имеет мало делителей, каждый N кусок времени мы вычитаем из открытого ключа произвольное число равное 5% от диапазона поиска и накапливаем оффсет. После чего делим уже новый открытый ключ, получившийся в результате сужения диапазона. Но так можно делить до второго пришествия:)
Также недавно запилил брутфорсер на CUDA, вполне возможно, что с рекордной скоростью в 6.2 Gkeys/s на RTX4090 (результаты достигнуты, есть скрины), но столкнулся с проблемой с железом. После 1.5 часа работы горячая GDDR6X "начинает кипеть" и сбрасывать частоту памяти, что сносит скорость до 4.9 Gkeys/s. Я как GPU майнер, при холодном ядре кипящие и визжащие банки памяти.
Сейчас пытаюсь это победить.
Silicon lottery в чистом виде.
Вот ссылки на проекты: https://github.com/Dookoo2
Нет конечно, я свой софт вообще нигде не презентовал, только на Bitcointalk. Это ведь не index calculus для Secp256k1, не найденная изогения или какой-то необычный эндоморфизм, и не успешное решение полиномов Семаева для ECDLP.
Допустим 1 поток, в потоке 256 кенгуру, поток делает 5 миллионов прыжков в секунду, каждый кенгуру проскачет X прыжков. Сменим на 32 кенгуру, за тоже время каждый кенгуру проскачет 8x прыжков. Кажется, что разницы практически нет, но она есть и это факт. При бОльшем количестве прыжков в секунду на 1 кенгуру решение находится быстрее. Если поставить меньше кенгуру в потоке, то уже играет модульная инверсия, она жрет под 50% тактов для сложения точек и скорость резко падает. При 32 кенгурухах в потоке скорость стандартная, без падений.
Мой Mark1 работает не совсем как классический вариант. Я сначала стартую tame kang, точки старта выбираются как диапазон/количество потоков. В каждом поддиапазоне стартуют 32 кенгуру с известным смещением от точки старта. Если они допрыгивают до конца поддиапазона, срабатывает механизм wrap и кенгуруху возвращают обратно в поддиапазон, при этом накапливая оффсет сиещения от точки старта. При прыжках коллектятся DP, сохраняются только уникальные точки.
Далее стартуют wild кенгуру в поддиапазонах также по 32 в поддиапазоне, точно также прыгают и как только напрыгают размер диапазона wrap возвращает ее обратно в поддиапазон. Ни одного прыжка вне диапазона поиска не происходит. Работает детектор циклов Brent, ведь прыжки детерминированы и если одна кенгуруха уже была на какой-то точке, то другая кенгуруха посетив туже точку будет прыгать точно как предыдущая, тем самым снизив нам количество возможных траекторий.
Так что тут особой магии нет, почти классика, но именно что почти.
AI пользовался, как без этого, но честно сказать даже самые мощные модели типа o3, доступные на тот момент, просто жесть как тупили. Но если точечно попросить что-то добавить или подсказать, то норм. С нуля брутфорсер не напишут 100% или времени затратишь x5 от чисто самописного кода.
По CUDA все еще хуже, на самом деле, так что тут больше сам, благо мануалов и примеров много. Радует то, что множество операций типа point mult можно сделать на хосте и потом передать подготовленные данные на GPU, а сам GPU выполняет только point add, никаких point mult или hash160 делать не надо, просто вынести самый горячий цикл на cuda + закинуть bloom в vram.
Я взял в среднем по 32 кенгуру на поток при 32 потоках. брать больше - снижать количество прыжков каждого кенгуру на единицу времени и чаще попадать в циклы. Брать меньше - уже плохо работает батчевая инверсия и не достигается нужная скорость. Ч разбил алгоритм на 2 фазы - сначала все ручные коллектят DP, потом фаза 2 - дикие прыгают и ищут DP. При условии сохранения таблицы DP ч готов заплатить 1 раз много времени чтобы сколлектить DP, но потом их переиспользовать при возможных последующих запусках. Сами прыжки детерминированы, одинаковый Seed ГСЧ при всех запусках, как и таблицы прыжков. Так что у меня в параллель дикие и домашние не скачут. При параллельном запуске это просто баланс 1 к 1, например дает уполовинивание скорости GPU так как дикие кенгурушки не коллектят DP, 1 к 3 чуть получше, DP попадаются реже, но сами дикие кенгуру скачут быстрее. Так что я не стал морочиться и разбил просто на 2 фазы. При моих тестах сочетание 32 потока по 32 кенгуру дают лучшее время до нахождения коллизии. В коде Mark1.cpp это константы K и K_DP их можно поменять и поиграть с составом кенгурух.
На моей тестовой GPU реализации совсем по другому, чтобы загрузить все SM по 128 CUDA ядер в каждом(RTX 4060) мне надо много кенгурух запускать в параллель, много это около 140.000, по 64 где-то кенгурухи на поток, а тысячи потоков.
Может искать до 256 бит.