id: Гость   вход   регистрация
текущее время 13:57 28/03/2024
Автор темы: Гость, тема открыта 22/07/2014 18:07 Печать
Категории: криптография, алгоритмы, хэширование, уязвимости, аутентификация
http://www.pgpru.com/Форум/Криптография/DKIMТехнологияИщуЛюдейКтоСпособенСоздатьБрутфорсДостойнуюОплатуГарантирую
создать
просмотр
ссылки

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


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


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


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


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


 
Комментарии
— Гость (22/07/2014 20:45)   <#>
А что, воровство DKIM-ключей уже не в моде (см. также это и это)? Разве DKIM считается настолько слабым, что его можно сбрутфорсить?
— SATtva (22/07/2014 20:57)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Не больше, чем RSA, но...
— Гость (22/07/2014 21:03)   <#>
Не больше, чем RSA, wwwно...

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

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

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


Просто странно – стандарт мощный, а реализация демонстративно никакая.
— SATtva (22/07/2014 22:28, исправлен 22/07/2014 22:29)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

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



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

— Гость (22/07/2014 23:11)   <#>

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

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

— Гость (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)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Даже если бы подобный offload был предусмотрен стандартом (а его там нет), к SMTP подобный трюк вы всё равно не прикрутите.
— Гость (24/07/2014 03:23)   <#>

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


Аутентифицирующий сервер? Kerberos?
— SATtva (24/07/2014 07:47)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Вполне возможно. DKIM имеет поддержку множественных алгоритмов подписи, но в основном стандарте предусмотрен только RSA + SHA256. Не знаю, вводились ли другими стандартами дополнительные идентификаторы.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3