DKIM технология, ищу людей кто способен создать брутфорс, достойную оплату гарантирую
Здравствуйте,ищу людей кто понимает в криптографии и способен написать брутфорс для подбора ключей DKIM.
Также если вы можете проконсультировать по вопросам сложности данных вычислений, времени которое потребуется для подбора данных ключей, а также если вы в состоянии руководить разработчиком, объясняя ему как и что делать, тоже пишите
Любая помощь или консультации будут очень щедро оплачены
Контакт для связи: viktorrodin6@gmail.com
Спасибо
Извините если не туда запостил
А что, воровство DKIM-ключей[link1] уже не в моде (см. также это[link2] и это[link3])?Разве DKIM считается настолько слабым, что его можно сбрутфорсить?Не больше, чем RSA, но...[link4]
384 или 512 бит в 2012 году? зачем же они так?
В коротких ключах есть определённый смысл — поток данных, проходящий через большой почтовый сервер, огромен (большие ключи создают существенную вычислительную нагрузку), а проверка аутентичности всё равно осуществляется практически в реальном времени. То есть если бы ротацию ключей проводили через разумные интервалы (через каждые несколько часов), проблемы бы не возникло.
Для защиты от спама допустимо короткое время секретности ключа.
А для проверки подлинности в задаче "этот абонент отправил мне такое сообщение, и DKIM сходится" хотелось бы большего ключа.
RSA1024 вычисляется в 4 раза дольше RSA512 (а проверяется только в 2 раза дольше), экономия на спичках.
Просто странно – стандарт мощный, а реализация демонстративно никакая.
Возможность долгосрочных проверок и не закладывалась в стандарт, он создавался только для защиты от спуфинга MX. Максимум, что можно обеспечить в качестве некоторого подобия — это кэширование ключей MX отправителя на стороне получателя.
Т.е. вместо одного сервера понадобится четыре. Для Гугла, возможно, спички, а для какой-то небольшой организации, может быть, и нет.
Танцуют всЁ. Россиянчегов ожидают неожиданные сливы писем, о достоверности которых с просторов своей жижи им будет втирать питерский какир.
Вот как раз у гугла это пожалуй не спички. С учётом количества писем это будет самое настоящее кц. :)
Как зовётся вариант, когда клиенту с сервера передается замаскированный ключ. Посредством которого клиент выполняет на своей стороне операции по ассиметричному шифрованию(тем же javascript), а сервер уже снимает маскирующий множитель с получившейся подписи?
всмысле подписывает (шифрует секретным ключом вычисленную хэш-сумму подписываемого сообщения).
подпись вслепую?
Нет, потому что подпись в слепую предполагает, что подписывающей стороне неизвестно содержимое того, что заверяется подписью.
А здесь же иной расклад — подписываемое содержимое известно, но надо переложить основные вычисления с одной стороны на другую в клиент-серверной системе.
Даже если бы подобный offload был предусмотрен стандартом (а его там нет), к SMTP подобный трюк вы всё равно не прикрутите.
Эллиптика всех спасёт?
Аутентифицирующий сервер?
Kerberos?Вполне возможно. DKIM имеет поддержку множественных алгоритмов подписи, но в основном стандарте предусмотрен только RSA + SHA256. Не знаю, вводились ли другими стандартами дополнительные идентификаторы.