Да, бежим и чепчики теряем переходить с RSA на ECDSA/ED25519.
Только ECDSA не constatnt time, так что понятно куда опять всех сгоняют.

На deprecated размере в 1024 бита и то ушло 9 часов и 160к попыток, а сколько потребуется на хотя бы актуальных дефолтных 2-3-4к бит ключах?
А сколько оно будет пыхтеть с моими 16к RSA бит ключами?

В остальном всегда стоит выбор: мы будем вываливатся с ошибкой сразу или мы будем тратить время и ресурсы зная что делаем бесполезную работу.
Как человек написавший с нуля реализацию ECDSA могу сказать что никто в здравом уме не станет писать constant time, потому что оно будет очень медленно работать.
Внизу DSA алгоритмов (кроме мутного 25519) лежат обычные математические библиотеки работающие с длинными числами и не делать там кучи оптимизаций на базе входных данных просто глупо.
Для 0, 1 в умножении делении всегда проще держать отдельную ветку сразу возвращающую результат.
Для чисел со степенью 2 проще делать банальный битовый сдвиг.
И там таких мест полным полно где расчёты можно или не проводить совсем или очень сильно упростить.
Такова природа этих крипто алгоритмов.

Решение тоже простое: не нужно лезть в алгоритмы и тратить время на поиски святого constant time, нужно добавлять рандомную задержку перед отправкой ответов.
В целом для этого можно даже какую то универсальную библиотеку враппер написать, в примитивном варианте она будет вызывать usleep() с рандомным числом после возвращения результата от криптооперации.
В продвинутом она будет замерять время затраченное на крипту и вести статистику чтобы автоматом выцепить верхний предел задержки и средний ожидаемый (нормальный) и дальше будет рандомизировать чтобы получать задержку между этими двумя числами.
В очень продвинутом оно вместо usleep() будет поддерживать очеред на отправку ответа с нужно задержкой.

Да, usleep() все не любят, всем надо по быстрее, с другой стороны вот "однострочный фикс": usleep(rand*10ms).
Он так же тупо покрутится на проце и погреет воздух.