DKIM технология, ищу людей кто способен создать брутфорс, достойную оплату гарантирую


Здравствуйте,ищу людей кто понимает в криптографии и способен написать брутфорс для подбора ключей DKIM.
Также если вы можете проконсультировать по вопросам сложности данных вычислений, времени которое потребуется для подбора данных ключей, а также если вы в состоянии руководить разработчиком, объясняя ему как и что делать, тоже пишите


Любая помощь или консультации будут очень щедро оплачены

Контакт для связи: viktorrodin6@gmail.com

Спасибо
Извините если не туда запостил

Комментарии
Гость (22/07/2014 20:45)   
А что, воровство DKIM-ключей[link1] уже не в моде (см. также это[link2] и это[link3])? Разве DKIM считается настолько слабым, что его можно сбрутфорсить?
— SATtva (22/07/2014 20:57)   
Не больше, чем RSA, но...[link4]
Гость (22/07/2014 21:03)   
Не больше, чем RSA, wwwно...

384 или 512 бит в 2012 году? зачем же они так?
— SATtva (22/07/2014 21:09)   
В коротких ключах есть определённый смысл — поток данных, проходящий через большой почтовый сервер, огромен (большие ключи создают существенную вычислительную нагрузку), а проверка аутентичности всё равно осуществляется практически в реальном времени. То есть если бы ротацию ключей проводили через разумные интервалы (через каждые несколько часов), проблемы бы не возникло.
Гость (22/07/2014 22:12)   
проверка аутентичности всё равно осуществляется практически в реальном времени. То есть если бы ротацию ключей проводили через разумные интервалы (через каждые несколько часов), проблемы бы не возникло

Для защиты от спама допустимо короткое время секретности ключа.
А для проверки подлинности в задаче "этот абонент отправил мне такое сообщение, и DKIM сходится" хотелось бы большего ключа.

RSA1024 вычисляется в 4 раза дольше RSA512 (а проверяется только в 2 раза дольше), экономия на спичках.


Просто странно – стандарт мощный, а реализация демонстративно никакая.
— SATtva (22/07/2014 22:28, исправлен 22/07/2014 22:29)   

Возможность долгосрочных проверок и не закладывалась в стандарт, он создавался только для защиты от спуфинга MX. Максимум, что можно обеспечить в качестве некоторого подобия — это кэширование ключей MX отправителя на стороне получателя.



Т.е. вместо одного сервера понадобится четыре. Для Гугла, возможно, спички, а для какой-то небольшой организации, может быть, и нет.

Гость (22/07/2014 23:11)   

Танцуют всЁ. Россиянчегов ожидают неожиданные сливы писем, о достоверности которых с просторов своей жижи им будет втирать питерский какир.
— sentaus (22/07/2014 23:12, исправлен 22/07/2014 23:12)   
Для Гугла, возможно, спички, а

Вот как раз у гугла это пожалуй не спички. С учётом количества писем это будет самое настоящее кц. :)

Гость (22/07/2014 23:46)   
Вот как раз у гугла это пожалуй не спички. С учётом количества писем это будет самое настоящее кц. :)

Как зовётся вариант, когда клиенту с сервера передается замаскированный ключ. Посредством которого клиент выполняет на своей стороне операции по ассиметричному шифрованию(тем же javascript), а сервер уже снимает маскирующий множитель с получившейся подписи?
Гость (22/07/2014 23:49)   
по ассиметричному шифрованию

всмысле подписывает (шифрует секретным ключом вычисленную хэш-сумму подписываемого сообщения).
Гость (23/07/2014 00:49)   
подпись вслепую?
Гость (23/07/2014 02:08)   
подпись вслепую?

Нет, потому что подпись в слепую предполагает, что подписывающей стороне неизвестно содержимое того, что заверяется подписью.
А здесь же иной расклад — подписываемое содержимое известно, но надо переложить основные вычисления с одной стороны на другую в клиент-серверной системе.
— SATtva (23/07/2014 08:25)   
Даже если бы подобный offload был предусмотрен стандартом (а его там нет), к SMTP подобный трюк вы всё равно не прикрутите.
Гость (24/07/2014 03:23)   

Эллиптика всех спасёт?


Аутентифицирующий сервер? Kerberos?
— SATtva (24/07/2014 07:47)   

Вполне возможно. DKIM имеет поддержку множественных алгоритмов подписи, но в основном стандарте предусмотрен только RSA + SHA256. Не знаю, вводились ли другими стандартами дополнительные идентификаторы.

Ссылки
[link1] https://www.pgpru.com/comment52900

[link2] https://www.pgpru.com/comment71041

[link3] https://www.pgpru.com/comment58477

[link4] https://en.wikipedia.org/wiki/DKIM#2012_usage_vulnerability