параметры Диффи-Хеллмана

нужны для т.н. «Perfect Forward Secrecy»

за подробностями в гугл и википедию

А вот для чего нужен dh?

Когда у тебя угонят приватные ключи, то:
- Если DH отсутствует, то можно расшифровать любой пакет с помощью секретного ключа адресата пакета.
- Если DH включен, то для расшифровки трафика нужно иметь полный дамп трафика от начала сессии, оба секретных ключа на руках, и расшифровывать всё по порядку с самого начала, походу реконструируя DH-сессию.

dh1024.pem хранит какие-то данные для запуска DH-сессии. Но по сути это скорее дырка для большого брата, без которой DH в SSL не работает, ИМХО.

реконструируя DH-сессию

Вот и эксперты по криптографии в треде нарисовались.

Но по сути это скорее дырка для большого брата, без которой DH в SSL не работает, ИМХО.

facepalm.jpg

Сертификаты и ключи используются для аутентификации сервера и клиента друг перед другом, DH используется для выработки совместного секретного ключа сессии.

Вот и эксперты по криптографии в треде нарисовались.

Опаньки, давай-ка аргументы, что при наличии полного дампа трафика от начала соединения и содержимого ключей и dh1024, нельзя что-то расшифровать.

Напомню, что:

Perfect forward secrecy ... means that the compromise of one message cannot lead to the compromise of others, and also that there is not a single secret value which can lead to the compromise of multiple messages.

... гарантирует, что сессионные ключи, полученные при помощи набора открытых и закрытых ключей долговременного пользования, не будут скомпрометированы, при компрометации одного из закрытых ключей.

Или ты из тех, кто думает, что существуют неуязвимые алгоритмы и криптосистемы, доступные неограниченно широкому кругу лиц, и позволяющие наглухо защититься от любой атаки?

facepalm.jpg

Смотри лицо не разбей: содержимое dh1024 можно генерить заново при каждом коннекте. Собственно, в этом и суть dh — уйти от статических ключей. Зачем случайное число сохранять на диск? В целях «оптимизации», прочитай недавнее интервью D. J. Bernstein'а на опеннете.

Собственно, в этом и суть dh — уйти от статических ключей. Зачем случайное число сохранять на диск?

Можно конечно генерить, да. Только этот процесс занимает рандомное недетерминированное время. Ты согласен на то, чтобы каждый твой защищённый коннект стартовал с задержкой от 1 до 100500 секунд? Попробуй позапускать openssl dhparam 1024 для эксперимента Тем не менее, менять его ручками хоть по 20 раз в день никто тебе не запрещает

Только этот процесс занимает рандомное недетерминированное время. Ты согласен на то, чтобы каждый твой защищённый коннект стартовал с задержкой от 1 до 100500 секунд?

Выхлоп /dev/urandom достаточен, сверхслучайность не требуется, т.к. ключ краткосрочный. Фактическое время генерации из urandom будет не более 100мс даже на гнилом роутере у которого проблемы с PRNG. OpenVPN коннекшен, напомню, поднимается секунду-две.

Попробуй позапускать openssl dhparam 1024 для эксперимента

Позапускал. Он собирает очень случайные байты для долгосрочного хранения, чтобы сымитировать надёжность. Это аргумент мимо кассы, просто пыль в глаза простым смертным.

почитал бы википедию хотя бы, что это такое и зачем нужно

Параметры Диффи-Хэллмана не просто рандомное число, а

    p является случайным простым числом
    (p-1)/2 также должно быть случайным простым числом (для повышения безопасности)[7]
    g является первообразным корнем по модулю p 

Позапускал. Он собирает очень случайные байты для долгосрочного хранения, чтобы сымитировать надёжность.

Он использует тот же /dev/urandom по дефолту

Да даже если прям требуется генерить по сертифицированному методу «openssl dhparam 1024» — можно делать это наперёд, в фоне. Держать в RAM несколько слотов, которые заполнять готовыми dh в фоновом потоке. Как только подключается клиент — брать готовый dh1024 из слота, и в фоне запускать генерацию нового. Проблема со скоростью генерации dh modulus надумана более чем, есть полно криптосистем с dh без файла со случайным числом: да тот же OTR например.

g является первообразным корнем по модулю p

Необходимость произвести полторы арифметические операции, отфильтровав неподходящие случайные байты — это прямо всё меняет радикально!

Дядя, запомни: dh1024.pem существует лишь потому что АНБ нужно уметь получать доступ твоему к VPN/HTTPS/etc трафику в любое время дня и ночи.

А ТС'у посоветую положить поделку OpenVPN на парашу истории, и посмотреть в сторону cjdns БЕЗ hyperborea. Это vpn, которая не хранит dh на диске, которая без центрального сервера работает, и с кучей прочих достоинств в плане безопасности.

Да даже если прям требуется генерить по сертифицированному методу «openssl dhparam 1024» — можно делать это наперёд, в фоне. Держать в RAM несколько слотов, которые заполнять готовыми dh в фоновом потоке. Как только подключается клиент — брать готовый dh1024 из слота, и в фоне запускать генерацию нового.

делай, кто-то запрещает что ли

только будь готов к постоянной загрузке процессора на 100%

Проблема со скоростью генерации dh modulus надумана более чем, есть полно криптосистем с dh без файла со случайным числом: да тот же OTR например.

может он там в исходниках захардкожен

Необходимость произвести полторы арифметические операции, отфильтровав неподходящие случайные байты — это прямо всё меняет радикально!

да, это требует времени. Сначала взять большое рандомное число, потом начать перебор от него, проверяя каждое число на простоту, затем найденные простые числа на предмет соответствия второму и третьему условию

Дядя, запомни: dh1024.pem существует лишь потому что АНБ нужно уметь получать доступ твоему к VPN/HTTPS/etc трафику в любое время дня и ночи.

И ты конечно же можешь подтвердить это ссылкой на публикацию в авторитетном источнике?

Опаньки, давай-ка аргументы, что при наличии полного дампа трафика от начала соединения и содержимого ключей и dh1024, нельзя что-то расшифровать.

С чего ты решил что я должен доказывать твою неправоту, когда доказательств своей правоты ты сам не привел ни разу?

Пока-что твои рассказы про реконструкцию DH-сессий (sic!) это сплошное словоблудие.

https://en.wikipedia.org/wiki/Philosophic_burden_of_proof
https://en.wikipedia.org/wiki/Argument_from_ignorance

Сообщение удалено shahid по причине а на*** спорить, если не догоняет (0)

Посмотри другие реализации dh в других криптосистема: otr, cjdns и ещё телега, у них у всех dh modulus динамический.

libotr-4.1.0/src/dh.c:

static const char* DH1536_MODULUS_S = "0x"
    "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD1"
    "29024E088A67CC74020BBEA63B139B22514A08798E3404DD"
    "EF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245"
    "E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7ED"
    "EE386BFB5A899FA5AE9F24117C4B1FE649286651ECE45B3D"
    "C2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F"
    "83655D23DCA3AD961C62F356208552BB9ED529077096966D"
    "670C354E4ABC9804F1746C08CA237327FFFFFFFFFFFFFFFF";
static const char *DH1536_GENERATOR_S = "0x02";

Так зашквариться на пустом месте — это талант надо иметь.

как я и предполагал :)

Если DH включен, то для расшифровки трафика нужно иметь полный дамп трафика от начала сессии, оба секретных ключа на руках, и расшифровывать всё по порядку с самого начала, походу реконструируя DH-сессию

Специалист в треде детектед. ДХ для того и нужен чтобы получить общий ключ, обмениваясь сообщениями в незащищенном канале (без возможности подмены сообщений злоумышленником).

Значит, имея все ключи на руках, и дамп трафика можно начинать ломать otr.

Теперь вопрос умным знатокам: почему в libssl генерация DH-прайма замедлена в 10^3 раз? dh «safe» primes там генерятся неск.секунд, хотя на её генерацию нужно куда меньше процессорного времени? А потом оказывается, что dh медленно генерится, и...

почему в libssl генерация DH-прайма замедлена в 10^3 раз?

Ссылка на код в студию.

ДХ для того и нужен чтобы получить общий ключ, обмениваясь сообщениями в незащищенном канале

Молодец, пять. Только как это относится к цитируемому тексту? Вот у тебя функция генерации dh есть:

int getRandom() {
  return 4;   // упрощённо содержимое dh1024
}

Ссылка на код гуглится по запросу openssl dh safe primes.

Значит, имея все ключи на руках, и дамп трафика можно начинать ломать otr.

А ключи существуют только на время сеанса и нигде не сохраняются. Откуда они у тебя на руках окажутся? :)

А ключи существуют только на время сеанса

А откуда эти ключи появляются?

алгоритм Диффи-Хэллмана обеспечивает

алгоритм Диффи-Хэллмана обеспечивает

Правильно. А зачем используется файл dh1024.pem, и почему без него DH в openssl не работает?
Наверное чтобы не тратить время на доступ к /dev/urandom и фильтрации оттуда байт.
С помощью похищенного секретного ключа/ключей мы можем расшифровать процесс установки dh-сессии. Мы видим все данные, которые обменивались клиенты, для вывода сессионного ключа. Далее, с помощью похищенного содержимого dh1024 и результатов DH-обмена мы получаем уравнение с одной неизвестной... Дальше, надеюсь, понятно?

Далее, с помощью похищенного содержимого dh1024 и результатов DH-обмена мы получаем уравнение с одной неизвестной

Уравнение, для решения которого нужно решить задачу дискретного логарифмирования. Удачи, лол.

dh1024 вообще не обязан быть секретным, это всего-лишь параметры алгоритма.

Далее, с помощью похищенного содержимого dh1024

его не нужно похищать, оно публичное по определению и его всё равно видно из перехвата трафика

С помощью похищенного секретного ключа/ключей

Секретные ключи для DH генерируются перед началом сессии и не сохраняются. Если ты их похитил из оперативки обоих машин, то значит у тебя уже есть физический доступ к ним, и ничего перехватывать и расшифровывать уже не нужно

почитай теорию

https://ru.wikipedia.org/wiki/Протокол_Диффи_—_Хеллмана

Уравнение, для решения которого нужно решить задачу дискретного логарифмирования.

В libssl, в жаве и некоторых других продукта долго не хотели имплементить dh > 1024. А когда уже наконец заимплементили, DSA 1024 признал «слабым» даже NIST, ещё наверное к 2010 году. К чему бы это, и как это противоречит моему высказыванию про АНБ?

dh1024 вообще не обязан быть секретным, это всего-лишь параметры алгоритма.

s/Похищен/перехвачен/g - граммар нази.

В libssl, в жаве и некоторых других продукта долго не хотели имплементить dh > 1024. А когда уже наконец заимплементили, DSA 1024 признал «слабым» даже NIST, ещё наверное к 2010

А я помню, как пользовался DH4096 до 2010 года :)

А я помню, как пользовался DH4096 до 2010 года :)

Я помню, как сгенерил RSA ключ на 64кб через easy-rsa.

DSA 1024 признал «слабым» даже NIST, ещё наверное к 2010 году.

И какое отношение DSA имеет к DH?

И какое отношение DSA имеет к DH?

Ну как же: обе упираются в задачу дискретного логарифмирования, и параметры DSA вроде как можно скормить на вход DH.

Мне понять хочется.
Вот взять другую известную программу использующую SSL-шифрование - OpenSSH. Получается в ней dh тоже есть, только хранится в RAM, а не на диске? И обмена ключами тоже как такового нет, кроме /etc/ssh/ssh_host_rsa_key.pub
OpenVPN таким способом настроить что, не возможно, чтобы установка соединения без обмена ключами шла, ключи бы и так находились на своих местах и их невозможно было похитить?

Получается в ней dh тоже есть, только хранится в RAM, а не на диске

А в /etc/ssh/moduli что хранится?

С помощью похищенного секретного ключа/ключей мы можем расшифровать процесс установки dh-сессии. Мы видим все данные, которые обменивались клиенты, для вывода сессионного ключа.

Нет, этих данных недостаточно для вывода секретного ключа.

Нет, этих данных недостаточно для вывода секретного ключа.

Часть обмена проходила телепатически.

У OpenVPN в доке написано, что DH 1024 — это вообще ок. 2048 — это вообще параноя, а 4096 — полный ахтунг и психиатрия. Доке сто лет, а все до сих пор делают статический dh1024 по дефолту, годами его не обновляют.

OpenSSH под 8192-bit клепает праймы и их много, а не один статический dh1024, который по сложности атаки в лоб соизмерим с похожим вышеупомянутым «слабым» DSA 1024.

В одной из док SSL написано, что генерация DH-прайма — это звиздец как ресурсоёмко и нужен целый кластер (в эру домашних кластеров и майнинга, и некоторые верят!), и потом кратко написано, что есть теоретическая возможность атаки на DH из-за переиспользования параметров DH-сессии, и чтобы её избежать нужно генерить dh prime во время «инсталляции».

В итоге можно рассмотреть сценарий, когда лицо, имеющее хороший кластер, выносит RSA-ключи через дырку heartbeat (или другую), кластером быстренько ломает «strong» DH 1024-битное простое целое, надежно сгенеренное openssl через отфильтрованный выхлоп /dev/urandom.

Все последующие сессионные ключи (renegation, согласно той же доке) ломаются без труда. Т.к. прайм лежит на диске, то взлом новой сессии с тем же праймом также не составит большого труда.

А чтобы все делали статическое 1024-бит prime, просто нужно сделать такую либу, которая будет генерить прайм по дефолту в 1000 раз медленее, и говорить всем что это такой strong prime и без него никак вообще. Этот алгоритм генерации забиваем в стандарт, а либу можно назвать OpenSSL, например, и сертифицировать по FIPS как очень секьюрную.

Часть обмена проходила телепатически.

Вот наглядное объяснение работы алгоритма DH: http://www.youtube.com/watch?v=vFjq9pID4-E

DH как раз и создан для защиты от пассивных атак.

содержимое dh1024 можно генерить заново при каждом коннекте
при каждом коннекте

а ничего что оно не генерируется за 1 секунду?

а ничего что оно не генерируется за 1 секунду?

Кажется, я уже писал, что DH и сертифицированная реализация DH в openssl «слегка» отличаются.

DH как раз и создан для защиты от пассивных атак.

Прочитай предыдущий комментарий. Разговор не про DH в целом, а про его переусложнённую реализацию в openssl.

UPD: Ещё раз повторю для вырывающих из контекста: я нигде не говорил, что можно взять и угадать DH-ключ. Но реализация DH в OpenSSL со всех сторон намекает как позволяющая существенно ускорить процесс угадывания тем, кто располагает вычислительными мощностями (упомянутая АНБ, например). DH prime в openssl генерится по сцец.алгоритму, который отбирает так называемые «strong» праймы вместо просто случайных. Это существенно повышает расходы времени (генерация идёт секунду и больше), и в теории позволяет при лобовом бруте ключа быстро отбрасывать бОльшую часть вариантов. Сабж про простые целые 1024 бит длиной, а на дворе 2015 год.

А альтернатива OpenSSL какая-нибудь есть?
Если уйти от использования OpenVPN, какие ещё есть методы создания шифрованного vpn-соединения? Если pptp-соединение запускать внутри ssh-тунеля, например, так возможно? Я снова про OpenSSH вспоминаю, потому как единственные сервера, использующие шифрование с открытым ключём, которые я имел опыт настраивать, это - OpenSSH и OpenVPN, хотя криптография кажется для меня крайне-интересным направлением.

Tinc и ещё раз tinc.

Зато ава очень гармонично смотрится с его утверждениями.