Шифрование в TLS/SSL | Защищенные сетевые протоколы
ฝัง
- เผยแพร่เมื่อ 5 ก.ค. 2024
- Лекция по шифрованию в семействе протоколов TLS/SSL. Страница учебного курса - www.asozykin.ru/courses/netwo...
00:00 - Приватность данных
02:45 - Симметричное шифрование
03:59 - Ассиметричное шифрование
05:15 - Гибридное шифрование в TLS/SSL
06:42 - Алгоритм обмена ключами RSA
08:20 - Совершенная прямая секретность (perfect forward secrecy)
09:55 - Алгоритм обмена ключами Диффи-Хеллмана
15:37 - Итоги
Добавляйтесь в друзья в социальных сетях:
вКонтакте - avsozykin
Instagram - / sozykin_andr
Facebook - / asozykin
Twitter - / andreysozykin
Мой сайт - www.asozykin.ru
Мой канал с краткими и понятными объяснениями сложных тем в ИТ и компьютерных науках - / andreysozykincs - วิทยาศาสตร์และเทคโนโลยี
Огромное спасибо за ваши лекции. 👍👍👍
Пожалуйста!
Вы один из лучших учителей Рунета. Огромная благодарность вам за вашу работу! Вашим студентам очень повезло!
О*рененное видео! Извините, не сдержался! :)
А почему при взломе серверов злоумышленники получали данные пользователя? Эти серверы используют шифрование не Диффи-Хэллмана, а менее стойкие? Или при хранении связки логин/пароль действуют другие принципы?
@@mazur_vg Любое шифрование можно декодировать, вопрос остается только во времени и затраченных ресурсах.
Очень простое и очень понятное, доступное объяснение. Так объяснять может только человек, глубоко разбирающийся в теме. Спасибо!
Пожалуйста! Рад, что понравилось!
Спасибо Андрей , Вы многому меня научили )) Все лекции по сетям просмотрел )
Пожалуйста! Рад, что лекции понравились!
Больше спасибо за лекции!!!очень помогает понять и раставить всё по полкам!Дай бог вам здоровья!!!!
Спасибо, контент радует
Очень интересна тема сетей
Пожалуйста! Рад, что тема заинтересовала!
Привет, Андрей Созыкин! Вы чудо) Спасибо большое за ваши видео, смотрю с удовольствием!
Пожалуйста! Рад, что нравится!
Благодарю вас за интересную лекцию!👍🏻
Спасибо за лекцию!)
Пожалуйста!
Благодарю, Андрей! Нужные вещи публикуешь!!!
Спасибо!
Андрей как всегда все четко и по существу
Супер урок, как всегда просто о сложном! Спасибо большое за такие уроки!
Пожалуйста!
Годные лекции, смотрятся на одном дыхании, спасибо!
Пожалуйста!
Андрей, спасибо большое! Очень понятно!
Пожалуйста!
Спасибо!!! Очень позновательно!!!
Пожалуйста!
Лекции потрясающие, спасибо
Пожалуйста!
Вроде в вузе проходили такое, но как всегда галопом. Вот сел привести эту тему в нормальный вид в голове. Спасибо огромное за лекции, у вас супер подробное обьяснение по каждой теме.
Очень круто и доступно! СПАСИБО!!!!!
Спасибо. Приятно слушать.
Очень понятно излагаете. Благодарю!
Спасибо!
Выражаю свою благодарность за ваш труд - очень доходчиво и лаконично. Было бы здорово видеть продолжение Ваших лекций, затрагивающие тему IPsec.
Спасибо за приятный отзыв. Про IPsec планирую записать лекции, но не в ближайшее время.
Спасибо. Полезный ролик
Пожалуйста!
Спасибо большое! Очень классный материал. Четко, ясно, понятно. Вы за 10 - 20 минут рассказываете то, что месяцами в вузе преподают. И сколько бы времени не прошло, такие отзывы будут эхом доноситься до Вас и по сей день
яростно плюсую
Я в 2010 году закончил ВУЗ по технической специальности. Был у нас классный препод. Но я по своему разгильдяйству забил на пары. Все это время работаю программистом и было лень разобраться в теме, хотя в общих чертах знаю как работают RSA и DH. Случайно наткнулся на ваш канал и этот плейлист....
Это ШЕДЕВР ))
PS: спасибо за качественный и доступный материал, пойду попробую жене обьяснить как работает TSL под капотом )) потренирую уровень усвоенного.
Спасибо за приятный отзыв! Успехов в объяснении жене ;-)
шик и блеск! Лайк вам, Андрей от СЕООНЛИ
вау! лекции просто супер!
Спасибо!
Не, ну это незамедлительный лайк и подписка. Спасибо за видосы!
Спасибо! Рад, что нравится!
Огромное спасибо! Отличный материал для чайников!
Пожалуйста!
Спасибо! Класное видео.
Пожалуйста!
Ну так разжевал! Спасибо! Блин! Математика рулит!
Пожалуйста! Рад, что понятно.
Математики здесь почти нет.
Очень классно!!! Спасибо Вам!!
А еще мне нравится ваша интонация в начале: "Приивет")
Спасибо!
Отличное видео. Коротко ясно
Спасибо!
Спасибо за видео!
Пожалуйста!
Спасибо очень интересно
Просто о сложном. Спасибо!
Пожалуйста!
Спасибо большое!
Крутой урок!
Спасибо!
Пожалуйста!
Спасибо за видео! У меня была много лет назад книжка по RSA4 , читал с увлечением, но понять не мог насчет разных ключей. А у вас наглядно разобрано как работает симметричный и ассиметричный ключи. И главное, было непонятно, зачем нужен открытый ключ, ведь его можно перехватить, и смысл ключа пропадает. Теперь все понятно:)
Пожалуйста! Хорошо, что удалось разобраться!
Большое спасибо!
Пожалуйста!
большое вам спасибо.
круто, интересно, понятно. Спасибо!
Пожалуйста!
шикарно!!
Спасибо!
Отличный урок
Спасибо!
Алгоритмы RSA и DH - это алгоритмы ассиметричного шифрования 4:40. RSA - самодостаточен, с помощью RSA мы можем опусить этап создания разделяемого ключа и передавать данные, зашифрованные открытым ключом, и данные будут прочитаны на сервере, но это работает в одну сторону, но если мы отправи открытый ключ от клиента к серверу, тогда это будет работать в две стороны - это даже звучит быстрее, чем DH (кстати, а почему так не делают?). DH - уже изначально предпалагает гибридный подход, ведь суть DH - генерация разделяемого ключа, поэтому его неправильно относить к алгоритмам ассиметричного шифрования, он же не самодостаточен.
Спасибо за ролик! Очень интересно!
Пожалуйста!
спасибо, лайк, подписка!
Спасибо!
DH - это оказывается просто!!!! Спасибо!
Не так сложно, как кажется. Но я рассказываю самый простой вариант, чтобы понять идею.
@@AndreySozykin Да! Именно принцип работы! Как от получает два одинаковых числа!
Прекрасное объяснение дх
Спасибо!
спасибо )) круто ))
Сууупер
Кучу лайков хочется поставить)
спасибо
Пожалуйста!
Андрей, спасибо вам! Небольшая просьба, если есть возможность, погромче бы записывать видео. Спасибо!
Все прекрасно слышно
спасибо!_)
Пожалуйста!
Нормальный курс по защите информации: данный плейлист.
Предмет «Защита компьютерной информации» у меня в колледже: 7 месяцев решаем ребусы по простейшим шифрам, 2 лекции и 1 работа по асимметричному шифрованию, окр, экзамен (тоже по ребусам).
Минский колледж кое-чего, гы.
Рад, что курс полезен! Жаль, что в колледже преподают не очень качественно.
😊👍
Лучшего объяснения на просторах интернета просто не существует. Андрей куда донатить ?
Спасибо, рад, что нравится. Донатить можно здесь - pay.cloudtips.ru/p/45a4055b
ты очень крутой
Спасибо!
👍
А защита от MITM как обеспечивается при Диффи-Хэллмане в TLS???
Алгоритм Диффи-Хеллмана будет работать до тех пор, пока не появятся достаточно мощные суперкомпьютеры?
Очень интересно. Однако конец 2021 и мы ещё сидим на РСА и протоколе тлс 1.2
Говоря про асимметричное шифрование, если клиент получает только открытый ключ, который лишь шифрует, как клиент будет умудряться расшифровывать сообщения сервера?
А если же клиент при помощи открытого ключа генерирует себе и закрытый, то не ставит ли это под удар всю технологию? Ведь любой может перехватить открытый ключ и с его помощью сделать себе закрытый?
👍🏻👍🏻👍🏻👍🏻
Я правильно понимаю, что при RSA нужен сертификат ( который содержит открытый ключ ) и закрытый ключ на сервере. А при алгоритме Диффи-хеллмана нужен только сертификат на сервере, а закрытый ключ будет сгенерён при установки соединения?
Большое спасибо за видео!
Вопрос - совершенная прямая секретность достигается только в случае ephemeral diffie-hellman? т.е. в случае когда для каждого соединения используется новый ключ?
tls.mbed.org/kb/cryptography/ephemeral-diffie-hellman
Да, именно так.
@@AndreySozykin спасибо за ответ, и за все лекции, это действительно лучшее что есть по теме на русском!
Здравствуйте. В описании опечатка. Должно быть: "03:59 - Асимметричное шифрование".
За видео большое спасибо. С меня лайк и подписка.
нет. это слайд симметричного шифрования.
@@manOfPlanetEarth Три года назад в таймкодах была опечатка. Я на нее указал, автор уже исправл.
@@VladGavrilov
👌🏼
скажи, какова у тебя судьба знаний, полученных из этих выпусков? пригодились для собеседования/работы или изучал просто из любознательности?:)
Отличное видео, спасибо. Есть 2 вопроса:
1 - Непонятно где это шифрование используется. Клиент - сервер это слишком размытое понятие. Это шифрование используется при запуске специальных программ по шифрованию или в протоколе Https или может быть где-то в другом месте?
2 - При настройке Https используется 5 сертификатов "Сертификат" "Корневой сертификат" "Промежуточный" "Приватный ключ" и "Запрос на получение сертификата". Что это за сертификаты и как они участвуют в шифровании?
1. Я рассказываю, как шифрование используется в протоколе TLS. Протокол HTTPS также использует TLS, подробнее об этом было в видео - th-cam.com/video/LTLqazCztnc/w-d-xo.html
2. Про сертификаты будет отдельное видео, через одно после обеспечения целостности сообщений в TLS/SSL.
Классные лекции. У меня возник вопрос: при объяснении работы алгоритма DH не ясно, как клиент и сервер узнали, что у них получилось одинаковое число - 16, они у вас окрашены красным и вы не говорили, что они их передают; И в конце не понятно, откуда клиент берёт восьмёрку для возведения в степень (3^5 mod 29)^8
На правильность и корректность не претендую, в теме разбираюсь слабо.
То, что клиент и сервер по окончании обмена имеют один и тот же ключ они знают, исходя из принципа работы алгоритма. Общая идея в том, что они генерируют одно и то же число разными путями, используя как открытую информацию (p, g), так и закрытую информацию (5, 8). Только закрытая информация используется косвенно - она передается как результат вычисления выражений с mod и в реальных условиях из нее вытащить эти секретные значения за разумное время не получится. По поводу второго вопроса я тоже не очень понял, что имелось в виду. Возможно, автор оговорился, и левая часть равенства относится к серверу, а правая - к клиенту (по крайней мере, в таком случае оно соотносится с рисунком).
10:03 каким образом клиент и сервер договариваются о числах p и g ? (29 и 3)
это открытые данные и они передаются открыто. (как сказал Андрей, то что зелёное открытые данные, то что красным закрытые) даже зная эти числа вы не сможите решить это уравнение. Я попробовал сам решить и получил, что у него 2^256 решений
но ведь ДН используется для генерации общего ключа, что он делает в ассиметричном списке?)
Потому что это алгоритм ассиметричного шифрования. Открытый ключ - числа p и g. Закрытый - числа, которые клиент и сервер сгенерировали случайным образом.
Добрый день, проблемой ассимитричного шифрования является то, что при получении злоумышником приватного ключа не будет соблюдаться "Совершенно прямая секретность", но ведь если злоумышник получит доступ к серверу, то он так же может получить доступ к симмитричному ключу DH (в нашем примере 16) и расшифровать все данные в данной сессии. Из-за этого не понятно как алгоритм DH обеспечивает "Совершенно прямую секретность" ?
P.s Спасибо большое за Вашу работу.
там при каждом соединении всё генерируется заново и затем ключи стираются. А вот почему это в RSA не реализовали, самому интересно
у меня был такой же вопрос
@@user-gg9ec2nm6i
ты что-то не то пишешь. а в DH что, реализовано обновление ключа при каждой новой сессии? это бессмыслица: DH - алг. создания закрытого ключа, применяй его как хочешь: хоть при каждой сессии, хоть один раз. DH как и RSA ничего не знает о соединении.
Большое спасибо за лекции! Небольшое уточнение - разве алгоритм Диффи-Хеллмана используется для ассиметричного шифрования? Вроде бы, наоборот для симметричного, конкретно в TLS для создания сеансового ключа. Поправьте меня, если ненправ.
согласен с тобой.
неизвестная ошибка проверки подлинности 23 ошибка SSL подключения безопасного канала schannel не получить рукопожатие SSL-соединения по протоколу TLS не (подскажите как это исправит)
К сожалению, не знаю. Неизвестная ошибка, поэтому причину понять сложно.
Спасибо большое за ролик! Кто нибудь может объяснить, почему у алгоритма Диффи-Хеллмана совершенная, прямая секретность? Ведь если мы перехватили данные, потом получили доступ к серверу (где есть ключ да расшифровки) - мы просто расшифруем данные и все, так?
Тоже не понимаю, как по мне это ошибка
Здравствуйте.
Я что-то не могу понять как так получается, что если сервер может расшифровать данные, а злоумышленник, получив доступ к серверу и его ключам - не сможет? Можете пояснить?
Спасибо.
Почему не сможет? Сможет. Именно поэтому стараются не хранить ключ на сервере долго и используют отдельные ключи для каждого соединения.
Я стал читать описание алгоритма RSA и не понял его отличия от DH, которое вы описываете.
Более того, я прочитал что DH используется только для Установления секретной связи, а не для шифрования.
Как-то всё оказывается сложнее...
А можно ли перехватить все ключи, используемые при передаче, тем самым расшифровать всё это?
Если получить доступ к закрытому ключу, то можно.
@@AndreySozykin спасибо за ответ!
Спасибо зп лекции, интересная тема, мало кем освещённая!
Вопрос по RSA, из лекции не понял принцип. Сервер имеет открытый зеленый и закрытый красный ключ. Передает клиенту зеленый ключ. Далее фраза: "Клиент получает открытый ключ и генерирует новый ключ шифрования". Генерирует на основе полученного зелёного ключа или случайным образом? Думаю случайный образом. Далее шифрует его зелёным ключом и передаёт серверу. Далее вопрос: если злоумышленник читает все данные, что ему мешает, имея зеленый ключ, расшифровать желтый ключ? Видимо то, что зеленый ключ не симметричный? Допустим.
Далее сервер получает желтый ключ. Тот, который сгенерированный клиентом случайным образом и зашифрованный зеленым ключом. Применяет к нему свой секретный красный ключ и получает исходный ключ, который сгенерировал клиент, и теперь у них обоих есть одинаковый ключ. Тогда, получается, красный ключ есть тот же самый зеленый ключ используемый в обратном направлении? Бред. Тогда злоумышленник может сделать все то же самое и получить ключ. Ну либо, если красный и зеленый ключи отличаются, то у клиента и сервера снова разных ключа и они не договорились об общем ключе. В чем подвох и чего я не понимаю?
Или всё на много проще! Зеленый и красный ключ - это суть один и тот же ключ, так сказать прямое и обратное преобразование. Берем слово, шифруем его зелёным ключом, расшифровываем его красным и получаем исходное слово. При этом, имея на руках зелёный ключ и результат его применения (слово в зашифрованном виде), невозможно определить что было за слово изначально, не имея красного ключа. Так? Тогда сходится)
Дв, именно так. Один ключ для кодирования, другой для декодирования. Поэтому и называется ассиметричное шифрование.
Посоветуйте учебный материал для более глубокого изучения криптографии, если знаний по математике глубоких нет.
Квантовая криптография. А.Альбов. От простого к сложному.
Добрый день, Андрей!
Отличные у вас лекции!
Но мне не понятны в чем преимущества алгоритма Д-Х?
- вычисленный ключ так же должен храниться на обеих сторонах, в Д-Х это ключ(16)?
но это тоже самое что и расшифрованный ключ от клиента в RSA, который должен на обеих сторонах храниться и получив к нему доступ можно расшифровать данные.
Что то я не совсем понял.
Ключи, рассчитанные по алгоритму Диффи-Хеллмана используются только для одного соединения. Для каждого нового соединения генерируются новые ключи. Хранить такие ключи незачем.
В RSA закрытый ключ у сервера постоянный. Поэтому он используется всегда. И если этот ключ окажется скомпроментирован, то можно будет расшифровать все данные (при условии, что зашифрованные данные сохранены).
@@AndreySozykin а HTTPS использует алгоритм Диффи-Хеллмана?
@@user-nu2kn7gp4n , добрый день. При соединении клиент и сервер договариваются и методе шифрования, и могут выбрать алгоритм Диффи-Хеллмана.
@@AndreySozykin но почему нельзя в таком случае для каждого нового соединения генерировать свою пару ключей, получать общий ключ, удалять пару? Тот же самый RSA остается.
Считаю что вам нужно закрепить вопрос от Дениса, так как это очень важная информация, которой нет в ролике.
у меня такой же вопрос почему в RSA нельзя было реализовать подобный механизм
В алгоритме RSA для того, чтобы расшифровать ключ симметричного шифрования (жёлтый), нужен закрытый ключ(красный). После завершения соединения сервер может удалить закрытый ключ, и как тогда злоумышленник при доступе к серверу расшифрует данные?
Спасибо за ролик, остальное в целом мне понятно.
Генерация открытого и закрытого ключа занимает много времени. Создавать их для каждого соединение TLS нерационально. Поэтому ключи используются достаточно долгое время.
@@AndreySozykin
вот оно что, Михалыч☝🏼
Такое надо озвучивать и акцентировать в ролике☝🏼
а почему Диффи-Хеллман это асимметричное шифрование, ведь там используется общий ключ, вычисленный по обеим сторонам?
Добрый день. Объясните пж. как получаются результаты 11 и 7.
3 в 5 степени 243 / 29= 8,37 остаток 3 округляем до 4 но это не 11 также и с результатом 7. Что я неправильно делаю.
Вы посчитали дробную часть. Про остаток от деления в Википедии прочитайте, оно по другому считается
Не подскажете, проверка подписей в биткоине происходит по такому же принципу? Как можно удостовериться, что узел является владельцем приватного ключа, лишь с помощью публичного ключа?
Про биткоин не знаю, к сожалению.
там используется улучшеный DH на элиптических кривых
Огромное вам спасибо. Наконец разобрался с этим алгоритмом. Хотел задать вопрос - нет ли здесь ошибки dl3.joxi.net/drive/2020/04/16/0009/2821/633605/05/f3fb1e7be6.jpg
Не должно ли это выглядеть как на скриншоте. Или я что-то не понял?
Не понял, в чем отличие формулы на скриншоте? Там возведение в степень показано знаком ^. Остальное вроде бы то же самое.
Вот - попробовал показать повторно - joxi.ru/MAj7QbpSjB1jVr.jpg
Эти операции коммутативны, значит порядок можно менять местами.
Простите можно вопрос. Если по алгоритму Диффи-Хеллмана требуется чтобы число p было минимум 1024 бита, то как может клиент работать с таким числом если максимальное значение цифровых литералов в языке javascript с помошю которого будет исполнятся обмен данными с сервером является именно 1024 бита. То есть число p всегда будет ровно максимальному 2**1024?
Насколько я понимаю, TLS реализуется в системном ПО на С/C++, а не JavaScript. Сам я JavaScript не знаю, поэтому не могу про него ничего пояснить, к сожалению.
@@AndreySozykin Спасибо за ответ. Благодарю за внимание))
да вы совершенно правы, когда мы инициализируем шифрование в JavaScript она под капотом обращается к библиотеке написанной на С++
а алгоритм DH симметричное или асимметричное?
а можно ли вообще на всякий случае алгоритмы DH и RSA комбинировать?
DH - ассиметричное шифрование.
Комбинировать их не желательно, т.к. сейчас алгоритм обмена ключами RSA обеспечивает менее слабую защиту, чем DH. Поэтому в целом безопасность снизится.
@@AndreySozykin
не "менее слабую защиту", а "более слабую защиту"😉
@@AndreySozykin
7:25
как на основе открытого ключа генерируется закрытый ключ? это что еще за алгоритмы? может, злоумышленник тоже может так сделать? или клиент держит эти алгоритмы в строжайшем секрете?
Спасибо за видео!
Возник вопрос: почему алгоритм DH обеспечивает совершенную прямую секретность? Если злоумышленник будет записывать все данные, а потом получит доступ к серверу и найдёт там симметричный ключ (в уроке - 16), то что ему помешает расшифровать всю предыдущую информацию? Ведь шифрование и дешифрование проводилось одним и тем же симметричным ключом (16), к которому у него теперь есть доступ.
Ключ генерируется для каждого соединения новый, а после окончания соединения удаляется.
@@AndreySozykin Понял, спасибо)
@@AndreySozykin Но ведь в таком случае и для RSA для каждого соединения должен генерироваться новый ключ и это верно для RSA алгоритма так же. Хотя в RSA такой характеристики не указано. Вы не могли бы написать пожалуйста почему для примера с RSA (слайд с обменом симметричными ключами) это не так?
меня тоже интересует этот вопрос. ИМХО так сложилось из-за нужности RSA в определённых условиях, поэтому он есть или просто разработка RSA2 остановилась, но это всё моё диванное мнение)
@@AndreySozykin Но ведь сохраняются данные уже расшифрованными вроде бы, так что какая разница, что там с ключом происходит? А если зашифрованными, то как их сервер расшифрует потом, если ключ каждый раз новый?
А разве злоумышленник не сможет перехватить те числа, о которых договаривались (были зелёными) и методом сложных математических вычислений узнать цифру ключа, которая в видео была "19"? Или я чет опять не понял
Может. Но для проведения вычислений ему понадобится несколько сотен лет.
@@AndreySozykin спасибо за ответ! Лучшие курсы, я бы у Вас учился с удовольствием :) Был приятно удивлен, когда узнал, что земляки)
А почему протокол Диффи-Хеллмана упоминается, как алгоритм асимметричного шифрования ?
Ведь данный протокол обычно используется для генерации общего сеансового ключа, которой в дальнейшем может использоваться для симметричного шифрования.
Генерация разделяемого ключа - одна из задач асимметричного шифрования.
@@AndreySozykin , спасибо за ответ !
@@AndreySozykin
асимметричное шифрование - это история же про открытый и закрытый ключи, а не про разделяемый ключ.
точнее, асимметричное шифрование - это история про шифрование одним ключом (открытым) и расшифрование другим ключом (закрытым).
+Plus
где же было это видео, когда цикада загадки делала?)
+
Отличное видео, как насчёт темы слудующего (ssh)
Будет еще несколько видео про TLS/SSL, а потом про HTTPS.
Затем, возможно, и про SSH напишу.
При чем здесь ssh? IPsec тогда уж проси.
@@w1tcherj
ну, хочет человек. душа просит!)
Не понял, почему Алгоритм Диффи-Хелмана обеспечивает совершенно прямую секретность. У хакера же есть возможность получить числа 29, 3, 7, 11 и 8 . Что я не понял?
Эти числа генерируются для каждой сессии и не сохраняются. Таким образом, если злоумышленник перехватит передаваемые данные и сохранит их, а через некоторое время получит доступ к серверу, то чисел для каждой сессии там не будет.
@@AndreySozykin Понял, спасибо) Успехов!)
А почему в алгоритме Диффи-Хеллмана обеспечивает совершенную прямую секретность?
Узнал?
@@Empty_line Нет(
Хм.. "злоумышленник получил доступ каким либо образом к серверу, а именно к закрытому ключу", а что мешает генерировать закрытый ключ на каждый отдельный сеанс. По такой логике, и алгоритм диффи хеллман не спасет, так как злоумышленник может получить доступ каким либо образом к серверу, а именно к этому самому числу 8, и после этого без проблем получить ключ синхронного шифрования. По сути что генерация закрытого ключа каждый раз, что генерация этого числа одно и тоже.
Генерация пары открытый-закрытый ключ требует значительного времени и вычислительных ресурсов. Поэтому их не разумно генерировать для каждого соединения.
@@AndreySozykin Я бы сказал что генерацию можно производить по тем же ограничениям, то есть закрытый и открытый ключ это число до 1024бита, и по сути работали бы они с одинаковой скоростью. По сути и так и так нужно генерировать. Но так как это новый стандарт наверно у криптографоф руки чесались ввести новый придуманный алгоритм или может он действительно безопаснее, хотя по сути единственный вариант взлома, который я вижу, это перебор чисел и попытка расшифровать пока не получим что-то осознанное. Хотя в первом варианте в ключе могли присутствовать и символы что на мой взгляд безопаснее, ну это так мысли я не криптограф.