Для WPA существуют калькуляторы для определения времени, необходимого для взлома ключевой фразы, но я ничего не нашел для OpenPGP.
Сколько времени потребуется, чтобы сломать 1024-битную зашифрованную электронную почту OpenPGP (в зависимости от мощности процессора)?
Меня также интересуют другие размеры клавиш, такие как 2048 и 4096.
Во-первых, я предполагаю, что вы говорите о RSA 1024-битном шифровании.
Как правило, тема слишком сложна, чтобы указывать простое число.
tl; dr: Взлом зашифрованного сообщения OpenPGP на одном процессоре невозможен и, вероятно, занимает годы даже при работе с большими вычислительными кластерами. Тем не менее, неизвестные (для общественности) математические недостатки могут изменить это на порядок, как это могут сделать квантовые компьютеры в будущем (далеко не с точки зрения "эпохи Интернета").
Немного более длинная версия:
В дополнение к 1024-битным ключам RSA это также относится к ключам большего размера. Большие ключи обеспечивают большую безопасность (в виде вычислительной мощности для их взлома), но помните, что безопасность не увеличивается линейно с размером ключа.
На бирже стека информационной безопасности есть хороший пост:«Как оценить время, необходимое для взлома RSA-шифрования?", которая не завершается оценкой типа" Используя модель Core i7 xy, вы сможете взломать 1024-битный ключ RSA за приблизительные z часов ", но ответы сходятся в том, что" 1024-битные ключи RSA не могут быть взломаны люди с обычно доступной вычислительной мощностью (т. е. горсткой высококлассных машин) в разумные сроки.
Обсуждение взлома 1024-битных ключей с гораздо большей вычислительной мощностью рассматривалось только с академической точки зрения:
Недавно я узнал, что начался выбор параметров для факторизации 1024-битного числа (это "мозговая" часть); просеивание технически осуществимо (оно будет дорогостоящим и потребует многих лет вычислений во многих университетских кластерах), но на данный момент никто не знает, как сделать часть линейного сокращения для 1024-битного целого числа. Так что не ожидайте 1024-битного перерыва в ближайшее время.
Это, вероятно, также относится к крупным хорошо финансируемым учреждениям с большим количеством вычислительных мощностей, таким как АНБ.
Вещи могут быстро измениться, если
Для DSA/ElGamal все немного по-другому. Ключ DSA того же размера, что и ключ RSA, обеспечивает большую безопасность, но в то же время DSA более уязвим к ошибочным случайным числам (сравните с ошибкой генератора случайных чисел в Debian). Криптография на основе эллиптических кривых, которая в настоящее время ожидается для OpenPGP, не имеет известных атак для поддерживаемых алгоритмов и в целом считается безопасной, но есть некоторые сомнения, особенно на кривых, рекомендованных NIST (NIST потерял довольно репутацию из-за случайного разбития Генератор чисел стандарт), и некоторые реализации придирки.
Для повышения производительности OpenPGP использует гибридное шифрование, поэтому сообщение шифруется симметричным шифрованием и случайным симметричным ключом (в OpenPGP, часто называемом "ключом сеанса"). Этот сеансовый ключ снова шифруется с использованием алгоритма асимметричного шифрования, например. RSA.
Если вы можете взломать ключ симметричного шифрования сообщения, вы также можете прочитать сообщение (в отличие от взлома асимметричного ключа, где вы можете прочитать все сообщения, зашифрованные с этим ключом).
В отличие от очень ранних версий PGP (в которых использовался алгоритм симметричного шифрования, разработанный самим Циммерманном под названием BassOmatic, который считается сломанным), все симметричные алгоритмы, определенные для OpenPGP, не имеют соответствующих известных атак.
Если кто - то не решил использовать не симметричное шифрование (что на самом деле это возможно!), Прервав сообщение с использованием алгоритма симметричного шифрования не следует считать возможным в настоящее время.
Хотя ответ @Jens Erat был довольно исчерпывающим, я исследовал возможность взлома RSA (алгоритм, стоящий за OpenPGP), поэтому я хотел бы остановиться на следующем:
Я порву с нормой и сначала дам TL; DR: вы не можете сломать этот ключ. Если мы посмотрим на это реалистично, у вас не будет способа вычислить 1024-битное целое число. Ваша лучшая возможная ставка - попытаться разорвать какую-то другую часть цепи безопасности (например, рабочий стол, где получатель проверяет свою электронную почту).
С реализмом вне пути, давайте рассмотрим возможные стратегии:
Слепое угадывание / Грубое принуждение. С 1024-битным полупериодом маловероятно, что это когда-нибудь сработает. Было бы лучше использовать ваше время случайным образом, пытаясь угадать номера лотереи.
Создание Радужного Стола. Возьмите догадки из факторинга, взяв каждое простое число меньше 2 ^ 1024 и умножив его на каждое другое простое число, сохранив результат в таблице. Тогда все, что вам нужно сделать, это найти правильную пару. Как вы можете себе представить, это тоже невозможно. Это будет связано с х! пары для х число простых чисел. С помощью функции подсчета простых чисел вы смотрите примерно 2,95 * 10 ^ 307 простых чисел - для сравнения предполагается, что число атомов в видимой вселенной составляет 10 ^ 83, поэтому даже если бы мы могли заставить каждый атом хранить два простых числа и их продукт так, чтобы наш компьютер мог индексировать это было бы невозможно.
Используйте сито поля общего номера. GNFS - ваш лучший выбор для факторинга большого полупериода. Он был использован Кляйнджунгом и его командой для расчета RSA-768, 768-битного полупростого числа. К сожалению, это заняло у его команды более трех лет, и это на несколько порядков меньше, чем те цифры, которые вы хотите учесть. Даже если бы вы тратили миллионы долларов (в день) на аренду лучших суперкомпьютеров на полную мощность, было бы практически невозможно рассчитать это число. Первый шаг GNFS - найти достаточно "отношений", которые позволяют решить подзадачи, и это может занять очень много времени.
Ваше последнее средство состоит в том, чтобы использовать квантовый компьютер, который позволил бы вам вычислять числа за приемлемое количество времени. К сожалению, их еще предстоит разработать до какой-либо степени полезности. Итак, на данный момент мы не можем учитывать 1024-битные и более полуприборы (и, следовательно, алгоритмы, которые на них полагаются).
