Там есть набор стандартных кривых, которыми (и только ими) тоже пользуются все:
openssl ecparam -list_curves
Пока, конечно, не опубликовано способа, который может ускорить вычисления закрытых ключей, сгенерированных над этими кривыми, но утверждать, что в ECDH/ECDSA совсем нет общих параметров, нельзя.
По-моему, было бы логично если и ограничивать доступ, то не на основе IP-адресов, а на криптографического токена/смарт-карты/апплета в EMV-карте. Некопируемо и предоставляет высокий уровень безопасности.
Лично мою паранойю давно жевала передача пароля по SMS в Сбербанке вкупе с историями о том, как мошенники заказывали перевыпуск SIM-карты и опустошали счета.
Секретные ключи генерируются на самом токене и никогда его не покидают (токен не дает экспортировать эти ключи). Открытые же части ключей при регистрации отправляются на сервисы, которые хотят аутентификации по этому токену. При самой аутентификации токен подписывает закрытым ключем случайную строку, сервис проверяет сохраненным открытым. Единственная проблема в этом случае — утеря/выход из строя токена.
Терминалы и турникеты в метро обычно расположены довольно близко друг к другу. NFC — тут я сказать не могу, т.к. не знаю, насколько сильная у «тройки» криптографическая защита и не получится ли так, что через месяц-другой после релиза пополнение станет уже и не очень нужным. Но в целом, я думаю, сказывается общая инертность — реализовывали фичу в последний месяц года, на который она была запланирована, приткнули куда пришлось, лишь бы работало, ибо это намного проще, чем выводить все троллейбусы и автобусы в онлайн и патчить валидаторы (причем, я думаю, еще и аппаратно) на всех автобусах.
P.S. Алсо, велосипедные станции проката, которые расставляет сбербанк, позволяют пополнять «тройку» с чипованной банковской карты. Это было бы даже удобнее, чем онлайн, если бы они работали (из тех 10 терминалов, что я попробовал, работал только один).
Потому что есть еще оффлайн-считыватели в троллейбусах и автобусах, которые могут опираться лишь на данные, записанные на карте. Потому нужно синхронизировать баланс в терминале после удаленного пополнения.
Исходники неоффициальные, в некоторых местах не деобфусцированные, но они отлично компилируются и запускаются. Набор инструментов для декомпила называется MCP, так же его использует Minecraft Forge.
2048-битный ключ — это такой огромный blob, который передать по другому (например, телефону) каналу весьма проблематично. Ключи допустимо передавать и через чат, но выводя отпечатки ключей на обоих сторонах. Тогда можно будет позвонить по тому же телефону и довольно быстро сверить эти отпечатки. Другой вопрос — если ключ используется в течении долгого времени, то где его хранить? cookies, localstorage — оба хранилища легко читаются контактовскими скриптами, а первое, кроме того, еще и на сервер VK посылается. Возможное решение — хранение шифрованного ключа в LocalStorage и запрос через функцию prompt() пароля. Но, я уверен, тут найдется еще куча приемов типа замены функций, благо JS позволяет.
Кроме того, можно использовать долговременные ключи только для аутентификации, а сам ключ шифрования получать посредством DH/ECDH, как это делает OTR. Это немного снизит опасность похищения ключей, т.к. предыдущую переписку расшифровать все равно не получится (Perfect forward secrecy).
Новые адреса создаются еще и для того, чтобы в автоматическом режиме (например, в интернет-магазине) отслеживать, кто же тебе переслал деньги — для каждого заказа генерируется свой адрес, и отслеживаются пополнения на эти адреса.
Конечно, но я и не говорил, что они не майнятся, не так ли? Факт остается фактом — далеко не каждое решение, принятое пулом, даст 50 монеток при соло-майнинге.
При майнинге в пуле учитываются частичные решения — решения при пониженной сложности — надо же как-то проверить, что пользователь X работал, а не просто ждал, пока другие найдут блок. Соло-майнинг частичных решений не учитывает.
Все новые транзакции включаются в блоки, которые, в свою очередь, нужно майнить. Правда, когда выработка новых монет закончится, сложность резко упадет — т.к. не все такие правильные и майнят исключительно во благо сети.
DSA требует использования случайных чисел при подписи. А что, если они будут не совсем случайные, а скажем, с битами закрытого ключа? Хотя это и требует куда более очевидных «протрояниваний», чем простое создание дефектных транзисторов, но не всей аппаратной криптографии можно доверять в надежде, что «не расшифруется»/«не проверится подпись».
Если вы хотите, чтобы твит прочитала группа людей — достаточно указать их, как получателей, и сообщение будет зашифровано с ключем каждого. Хотя я вообще слабо представляю, какое PGP сообщение влезет в твит.
Он будет зашит в кристалл. Исследователи, при желании, могут даже этот кристалл растворить, уткнувшись в микроскопы. Только проблема в том, что запустить чужую машину извлеченный ключ не поможет, а поможет он только сварганить эмулятор брелка для своей.
Пока, конечно, не опубликовано способа, который может ускорить вычисления закрытых ключей, сгенерированных над этими кривыми, но утверждать, что в ECDH/ECDSA совсем нет общих параметров, нельзя.
Лично мою паранойю давно жевала передача пароля по SMS в Сбербанке вкупе с историями о том, как мошенники заказывали перевыпуск SIM-карты и опустошали счета.
P.S. Алсо, велосипедные станции проката, которые расставляет сбербанк, позволяют пополнять «тройку» с чипованной банковской карты. Это было бы даже удобнее, чем онлайн, если бы они работали (из тех 10 терминалов, что я попробовал, работал только один).
Кроме того, можно использовать долговременные ключи только для аутентификации, а сам ключ шифрования получать посредством DH/ECDH, как это делает OTR. Это немного снизит опасность похищения ключей, т.к. предыдущую переписку расшифровать все равно не получится (Perfect forward secrecy).
скорее всего, об атаке на поиск коллизии. Атака на поиск прообраза осуществима только брутфорсом.