34:10 По HTTPS немного не точно, но допустимо для обьяснения. Симетричный (сессионный) ключ не пересылается зашифрованым асиметрично - как раньше (давным давно - очень давно - в 2015 уже так не делали.), он генерируется из определенных данных, с обеих сторон пересылаемых во время соединения TLS/SSL, по протоколу Диффи-Хелмана. Cервер не проверяет клиента, клиент проверяет сервер, или наоборот, сертификат служит для идентификации и аутентичности сервера. Сеансовый ключ не шифруется ассиметричной криптой.
хорошо изложен материал по цифровой подписи. Что касается SSL есть недопонимание которое может ввести в заблуждение или привести к вопросу что задавал "webdeveloper" ниже (Возможно скорее всего ето я чего то не понял). Поетому на счет SSL советую прочесть еще какую то литературу. Google вам поможет. Автору огромное спасибо продолжай. Хотелось еще чтобы автор поделился опытом работы в администрировании баз даных. Ну карты ему в руки, и ещераз спасибо за его роботу.
Все понятно и просто супер. А как на никсах все Например если свой внутрикорпаративный сервис подымем и самоподписной ключ на него повесим и пользователям генерить для входа Тулкит интересно было бы посмотреть
Спасибо. У Вас без сомнения дар чисто и просто объяснять. До Вас всё слушала только на английском. Так что Вы лучший на рускоязычном пространстве. При работе с Сервером Сертификации, сертификатами и шифрованием имела непонятные нюансы, которые делала на автомате. У Вас же получила разъяснение. Приятно также, что Вы доброжелательны и незаносчивы. Только один момент - Вы не знаете, как правильно произносить английские слова. Режет ухо. Это вечная проблема для российских IT-специалистов. Прослушайте американцев/англичан. Спасибо за Ваши старания.
вот уж неправда. в большинстве случаев он всё правильно произносит, и сильно выбивающегося ничего нет. ну может совсем иногда. бывает в десятки раз хуже. здесь все относительно неплохо.
Еще на счет EFS, когда закончится срок действия сертификата, то мы потеряем доступ к данным? Менять время на ПК назад? )) Или надо успеть убрать шифрование и перешифровать заново, чтобы выпустился новый сертификат?
И в цепочке сертификатов имена центров сертификации не совпадают. Issued by видимо тут используется не просто имя, а какой-то уникальный идентификатор ?
Добрый день. Как ситуация на текущий мент с актуальной областью администрирования. Я смотрю в сторону системного архитектора и виртуализации. Как на Ваш взгляд это перспективно или лучше пересмотреть направление? Спасибо за урок.
Добрый! Лично я бы пошел в разработку, если бы мог выбрать вновь :) ИМХО, через 15-20 лет 95% администрирования тупо уйдет в облака, которые будут админить привязанные к вендору специалисты. Хотя сейчас проблем с трудоустройством нет (по крайней мере в мск)
@@TrainITHard Я как раз начал с Java, но администрирование показалось проще и понимания побольше изначально, поэтому временно переключился. Т.е. Java, PYTON и например С# перспективнее на Ваш взгляд?
@@TrainITHard ну и отпугнуло в программировании вероятность стать "аутистом", все таки у админов задач побольше и разнообразные. Сам по последним размышлениям думал двигать в сторону системного архитектора.
@@tyyyyuuuuuuuuijjjiio по программированию ничего не знаю, поэтому не подскажу :) по поводу задач, очень сомневаюсь, что у админов их больше и они разнообразнее.
Не очень понял у нас есть рутовый центр сертифиаций и он отдает свой откртый ключ другому центру сертификаций что бы он был доверенным? и получается если человек хочет проверить действительный ли этот сертификат он его отравить для его проверки в рутовый центр сертификаций или как?
Чтобы CA стал доверенным, рутовый CA подписывает серт дочернего CA закрытой частью своего ключа. Далее любой человек может проверить доверенность дочернего CA путем проверки подписи открытым ключем рутового CA.
Есть неясность : когда шифруем файл 2.txt (59:35) Вы говорите, что он зашифрован симметричным ключом, а симметричный зашифрован закрытым ключом. Затем, когда мы экспортируем сертификат, мы зачем-то экспортируем закрытый ключ. Но ведь закрытым нельзя расшифровать то, что было зашифровано закрытым (1:01:50) ... Еще непонятно зачем шифровать симметричным, а потом асимметричным, когда можно использовать только асимметричный (а где тогда лежит ключ от симметричного шифрования? )
Действительно, это ошибка в видео. Симметричный ключ шифруется открытым ключем. Вот схемка: upload.wikimedia.org/wikipedia/commons/thumb/a/a6/EFS_operation_scheme.png/400px-EFS_operation_scheme.png По второму вопросу, отвечал еще в видео. Асимметричное шифрование требует намного больше вычислительных ресурсов, нежели симметричное шифрование, поэтому даже SSL/TLS (например HTTPS) асимметрично шифруют только симметричный ключ, но не сами данные.
"самый главный плюс ассим - что не надо передавать ключ по сети". Ну так и при симметр если не передавать то будет все ок. Дело то не в этом, а в том что нам надо попасть в ситуацию когда на обоих концах будет возможность шифровать/дешифровать не пересылая ключ по сети с этого надо начинать.
не пересылая ключ по сети - это по телефону звонить что-ли?) ассиметричное шифрование как раз позволяет передавать открытый ключ по сети, при этом сам ключ не компрометируется, так как расшифровать без закрытого ключа (который никуда не передается) все равно ничего не получится
24:20 что мешает тому же злодею подделать всю цепочку вышестоящих сертификатов в т.ч. рута? Или как вообще убедиться что РУТ сертификат это подлинный РУТ сертификат?
8:25 - Действительно не ясно откуда у второго пользователя ключ для расшифровки и что это за ключ - публичный? Выходит любой может открыть это сообщение. Я думаю механизм хорошо описан здесь: ua-cam.com/video/NmM9HA2MQGI/v-deo.html (дискламер - это на английском.) 12:56 Получается цифровая подпись только проверяет не было ли изменено сообщение и не было ли оно подменено кем-то, но само сообщение она не защищает.
1. ключ для расшифровки уже есть у пользователя (закрытый ключ). пользователь передает открытый ключ тому, кому нужно что-то зашифровать, данные шифруются открытым ключем и далее могут быть открыты только пользователем с закрытым ключем. то есть для шифрования, отправитель сначала получает открытый ключ адресата. 2. все верно, она только покажет если сообщение изменилось при передаче
16:39 Сертификат + открытый ключ в нем, передается в структуре эцп, получатель не запрашищает ключ у сервера, клиент (почта, ворд, адоби) извлекает сертификат проверяет его на валидность делает проверки касающиеся сетртификата, потом извлекает из сертификата открытый ключ, обрабатывает сообщение получает хэш сообщения/файла, расшифровывает открытым ключем зашифрованный отправителем на его закрытом ключе хэш в структуре эцп, сравнивает хэши с тем что получил ранее с сообщения или файла, если хэши совпадают валидность сообщения/файла подтверждается, если нет то сообщение/файл былo скомпрометированно и, сообщение/файл было изменено по дороге, и не проходит валидацию по эцп. Таким образом понятно, было-ли сообщение/файл скомпрометированно/н.
Никак, если не выпускать сертификат с помощью публичного платного центра сертификации. Цвет строки определяет браузер в зависимости от сертификата. Сам сертификат верифицируется публичными ЦС разными способами: например можно только валидировать домен по почте в этом домене - тогда ни о какой зеленой строке речи не будет, а можно валидировать домен и организацию, предоставив бухгалтерские документы - это уже расширеная валидация и такой сертификат будет показан зеленым. Погуглите услуги extended validation certificate у публичных ЦС.
TrainIT Hard я помню что нужно поди создать политику в AD CS а потом в меню Extended Validation их добавить, делаем для EV Subordinate CA во все шаблоны политику и доп.поля и готово!
Я бы даже и 4 кб ключ посоветовал, различие в том, что ясно понятно что RSA-1024 не защищен, но для поиска ключа 2048 бит нужно найти 2 пары открытых и закрытых, а для поиска 4096 бит, тут уже будет очень не сильно просто, в рекомендации ECC-521 и DES-1024
EV никогда не делал - зачем он, если серт непубличный? :) По ключу можно и 4096, только не забываем про обратную совместимость - например старые циски не умели в ключи длиннее 2048.
Стоп! Я ещё смотрю видео. насчет цифровой подписи. как же пользователи узнаёт, что открытый ключ, который у него имеется, действительно принадлежит тому, Чьи данные он хотел бы получить?
Потому что, если он попытается расшифровать подпись чужим открытым ключом, у него ничего не выйдет, так как пара открытый-закрытый ключ математически взаимосвязана.
Публичный ключ формируется на основе приватного (по крайней мере в openssl). Если это не математическое соотношение, то что это? И сомнительно, что публичным ключом можно расшифровать сообщение, зашифрованное приватным ключом. Что же это получается? У всех есть публичный ключ сервера (на то он и публичный), и все (включая ФСБ) могут расшифровать то, что сервер шифрует приватным ключом и шлет исключительно Маше? Хуйня собачья. Публичный ключ используется только для шифрования. Далее только сервер может расшифровать это своим приватным ключом. И насколько я успел разобраться (отнюдь не благодаря этому видео), так браузер передает симметричный сессионный ключ, который он сгенерировал, и который будет использован в дальнейшем уже симметричном шифровании, т.к. асимметричное слишком вычислительно-затратное. Хотелось бы узнать, как работает сертификат, с помощью которого браузер убеждается, что человек посередине не подменил публичный ключ сервера, но, что-то подсказывает мне, что в этом говно-видео это вряд ли освещается.
Все, что нужно знать - SSL это древний протокол и сейчас почти нигде не используется. Все что сейчас называют SSL, на самом деле является TLS в 99% случаев.
Тогда какая тут безопасность, если открытый ключ может расшифровать то, что зашифровано закрытым? Ладно, вопрос безопасности пока не важно, потом сам разберусь, почитав что-нибудь)
TrainIT Hard, вот тут момент объясните, плиз. Получается мы шифруем хэш закрытым ключем и отправляем. Хакер это перехватывает. Он сможет закрытый ключ извлечь из этого и потом перехватить и открытый, который свободно гуляет и расшифровывать вообще что угодно у этого пользователя?
![[Windows Server 2012 basics] Урок 8 - Доверие и группы безопасности в Active Directory](http://i.ytimg.com/vi/dKNPYX4yQbg/mqdefault.jpg)
![[Windows Server 2012 basics] Урок 11, часть 1 - Certification Authority, теория и установка](http://i.ytimg.com/vi/WK9FSaXQARU/mqdefault.jpg)
1:30 Симметричное шифрование
6:36 Асимметричное шифрование
12:27 Цифровая подпись
18:31 PKI Инфраструктура открытых ключей
- - - 19:30 Сертификат
- - - 24:20 О Центрах сертификации
- - - 28:53 Доверие и Root ЦС
30:28 SSL
35:10 Практика: Консоль, управление компьютерным и пользовательским сертификатом
- - - 38:08 Ключик на сертификате
40:00 Доверенные корневые сертификаты
40:55 Доверенные лица
42:05 Рассматриваем сертификат
48:28 Политики сертификата
51:59 Точки распространения списка отзывов в сертификате
56:30 Эксперименты: EFS
1:07:50 Эксперименты: Web сайт
1:11:00 Поведение сертификата при отзыве
- - - 1:13:30 Самоподписанный сертификат
- - - 1:18:04 Очистить кэш отозванных сертификатов
1:24:10 Классификация админов
34:10
По HTTPS немного не точно, но допустимо для обьяснения.
Симетричный (сессионный) ключ не пересылается зашифрованым асиметрично - как раньше (давным давно - очень давно - в 2015 уже так не делали.), он генерируется из определенных данных, с обеих сторон пересылаемых во время соединения TLS/SSL, по протоколу Диффи-Хелмана.
Cервер не проверяет клиента, клиент проверяет сервер, или наоборот, сертификат служит для идентификации и аутентичности сервера.
Сеансовый ключ не шифруется ассиметричной криптой.
Все круто, молодец! Хочется больше и больше смотреть твои уроки. Все четко объясняешь. Успехов тебе!
это самое лучший урок по теме, из всех что я видел! Чувак, ты крут!!
+Виталий Ситников Спасибо!
Уроки реально помогают освежить знания в голове. Спасибо, четкое объяснение 👍
Очередное, но огромное СПАСИБО! многое прояснилось у меня в голове!
Спасибо за видео!
Начал понимать что к чему.
Важные знания по защите информации. Спасибо за урок!
Спасибо, интересная лекция. С удовольствием послушал, покликал у себя на компе.
Спасибо за вашу работу, отлично подан материал, многое понял.
Огонь, разложил по полкам всё что у меня в голове было)) Спасибо))
красавчик , стало укладываться все в голове !
Спасибо тебе огромное за уроки!!!
Блогодарю за такой крутой урок реально респект
За один урок узнал и понял больше чем за курс нудных лекций. Спасибо!!
В этом беда образования.
Чувак ты мега крут, спасибо за такие уроки.
Лучшее видео по теме PKI. Жаль канал как-то затих...
Урок просто супер! Все понятно! Скоро собеседование! Ты крут!
Собеседование прошел?
@@romankrylov3504 тоже интересно, хоть и три года прошло, а чувак то даже заходит через этот акк. Но что то не как не ответит. Жаль...
Слыш, сyчара, к тебе уважаемые люди обратились.
Ну чтож, на днях и я на собеседование пойду.
@@sketchturner3496 что за фирма и какая должность?
хорошо изложен материал по цифровой подписи. Что касается SSL есть недопонимание которое может ввести в заблуждение или привести к вопросу что задавал "webdeveloper" ниже (Возможно скорее всего ето я чего то не понял). Поетому на счет SSL советую прочесть еще какую то литературу. Google вам поможет. Автору огромное спасибо продолжай. Хотелось еще чтобы автор поделился опытом работы в администрировании баз даных. Ну карты ему в руки, и ещераз спасибо за его роботу.
Все понятно и просто супер.
А как на никсах все
Например если свой внутрикорпаративный сервис подымем и самоподписной ключ на него повесим и пользователям генерить для входа
Тулкит интересно было бы посмотреть
Хороший урок)
Спасибо. Толково
Насчет фрагмента с сертификатом майкрософта, политика там active directory, ее можно самим сделать
Какой хороший мальчик! oo)) Спасибо
я не сразу врубился о чём)) да, хороший
Спасибо. У Вас без сомнения дар чисто и просто объяснять. До Вас всё слушала только на английском. Так что Вы лучший на рускоязычном пространстве. При работе с Сервером Сертификации, сертификатами и шифрованием имела непонятные нюансы, которые делала на автомате. У Вас же получила разъяснение. Приятно также, что Вы доброжелательны и незаносчивы. Только один момент - Вы не знаете, как правильно произносить английские слова. Режет ухо. Это вечная проблема для российских IT-специалистов. Прослушайте американцев/англичан. Спасибо за Ваши старания.
вот уж неправда. в большинстве случаев он всё правильно произносит, и сильно выбивающегося ничего нет. ну может совсем иногда. бывает в десятки раз хуже. здесь все относительно неплохо.
А вы слушали индусов на минуточку?)
Саш спасибо!
Спасибо !
Еще на счет EFS, когда закончится срок действия сертификата, то мы потеряем доступ к данным? Менять время на ПК назад? )) Или надо успеть убрать шифрование и перешифровать заново, чтобы выпустился новый сертификат?
Классные уроки! Оставили бы ссылку на донаты.
1:24:40 по SQL Server? Lync, Exchange, IIS, ... не планируются курсы?
Exchange возможно, IIS был
Спасибо из 2022
И в цепочке сертификатов имена центров сертификации не совпадают. Issued by видимо тут используется не просто имя, а какой-то уникальный идентификатор ?
Еех, говорила мама - "учи 1С". Щас бы проблем не знал. Админствотака же вещь непостоянная
Добрый день. Как ситуация на текущий мент с актуальной областью администрирования. Я смотрю в сторону системного архитектора и виртуализации. Как на Ваш взгляд это перспективно или лучше пересмотреть направление?
Спасибо за урок.
Добрый!
Лично я бы пошел в разработку, если бы мог выбрать вновь :) ИМХО, через 15-20 лет 95% администрирования тупо уйдет в облака, которые будут админить привязанные к вендору специалисты. Хотя сейчас проблем с трудоустройством нет (по крайней мере в мск)
@@TrainITHard Я как раз начал с Java, но администрирование показалось проще и понимания побольше изначально, поэтому временно переключился.
Т.е. Java, PYTON и например С# перспективнее на Ваш взгляд?
@@TrainITHard ну и отпугнуло в программировании вероятность стать "аутистом", все таки у админов задач побольше и разнообразные. Сам по последним размышлениям думал двигать в сторону системного архитектора.
@@tyyyyuuuuuuuuijjjiio по программированию ничего не знаю, поэтому не подскажу :) по поводу задач, очень сомневаюсь, что у админов их больше и они разнообразнее.
Не очень понял у нас есть рутовый центр сертифиаций и он отдает свой откртый ключ другому центру сертификаций что бы он был доверенным? и получается если человек хочет проверить действительный ли этот сертификат он его отравить для его проверки в рутовый центр сертификаций или как?
Чтобы CA стал доверенным, рутовый CA подписывает серт дочернего CA закрытой частью своего ключа. Далее любой человек может проверить доверенность дочернего CA путем проверки подписи открытым ключем рутового CA.
Есть неясность : когда шифруем файл 2.txt (59:35) Вы говорите, что он зашифрован симметричным ключом, а симметричный зашифрован закрытым ключом. Затем, когда мы экспортируем сертификат, мы зачем-то экспортируем закрытый ключ. Но ведь закрытым нельзя расшифровать то, что было зашифровано закрытым (1:01:50) ...
Еще непонятно зачем шифровать симметричным, а потом асимметричным, когда можно использовать только асимметричный (а где тогда лежит ключ от симметричного шифрования? )
Действительно, это ошибка в видео. Симметричный ключ шифруется открытым ключем. Вот схемка: upload.wikimedia.org/wikipedia/commons/thumb/a/a6/EFS_operation_scheme.png/400px-EFS_operation_scheme.png
По второму вопросу, отвечал еще в видео. Асимметричное шифрование требует намного больше вычислительных ресурсов, нежели симметричное шифрование, поэтому даже SSL/TLS (например HTTPS) асимметрично шифруют только симметричный ключ, но не сами данные.
"самый главный плюс ассим - что не надо передавать ключ по сети". Ну так и при симметр если не передавать то будет все ок. Дело то не в этом, а в том что нам надо попасть в ситуацию когда на обоих концах будет возможность шифровать/дешифровать не пересылая ключ по сети с этого надо начинать.
не пересылая ключ по сети - это по телефону звонить что-ли?)
ассиметричное шифрование как раз позволяет передавать открытый ключ по сети, при этом сам ключ не компрометируется, так как расшифровать без закрытого ключа (который никуда не передается) все равно ничего не получится
ну по сути да, первопричина именно в этом
24:20 что мешает тому же злодею подделать всю цепочку вышестоящих сертификатов в т.ч. рута? Или как вообще убедиться что РУТ сертификат это подлинный РУТ сертификат?
8:25 - Действительно не ясно откуда у второго пользователя ключ для расшифровки и что это за ключ - публичный? Выходит любой может открыть это сообщение.
Я думаю механизм хорошо описан здесь: ua-cam.com/video/NmM9HA2MQGI/v-deo.html (дискламер - это на английском.)
12:56 Получается цифровая подпись только проверяет не было ли изменено сообщение и не было ли оно подменено кем-то, но само сообщение она не защищает.
1. ключ для расшифровки уже есть у пользователя (закрытый ключ). пользователь передает открытый ключ тому, кому нужно что-то зашифровать, данные шифруются открытым ключем и далее могут быть открыты только пользователем с закрытым ключем. то есть для шифрования, отправитель сначала получает открытый ключ адресата.
2. все верно, она только покажет если сообщение изменилось при передаче
@@TrainITHard Спасибо, разобрался!
16:39
Сертификат + открытый ключ в нем, передается в структуре эцп, получатель не запрашищает ключ у сервера, клиент (почта, ворд, адоби) извлекает сертификат проверяет его на валидность делает проверки касающиеся сетртификата, потом извлекает из сертификата открытый ключ, обрабатывает сообщение получает хэш сообщения/файла, расшифровывает открытым ключем зашифрованный отправителем на его закрытом ключе хэш в структуре эцп, сравнивает хэши с тем что получил ранее с сообщения или файла, если хэши совпадают валидность сообщения/файла подтверждается, если нет то сообщение/файл былo скомпрометированно и, сообщение/файл было изменено по дороге, и не проходит валидацию по эцп.
Таким образом понятно, было-ли сообщение/файл скомпрометированно/н.
Да, я описывал логику процесса. В частном случае проверки системой подписи все так, как вы описали.
@@TrainITHard Мне нравятся ваши лекции, информация плавно ложится в мозг, без стресса :-), еще-бы про квантовую крипту и пост-квантовую.
771 страница. Сейчас читаю эту книгу.
Что за книга?
А как сделать в AD CS 2012R2 голубую или зеленую строку, да и вообще сертификат с конфигурацией со своими параметрами строки
Никак, если не выпускать сертификат с помощью публичного платного центра сертификации. Цвет строки определяет браузер в зависимости от сертификата. Сам сертификат верифицируется публичными ЦС разными способами: например можно только валидировать домен по почте в этом домене - тогда ни о какой зеленой строке речи не будет, а можно валидировать домен и организацию, предоставив бухгалтерские документы - это уже расширеная валидация и такой сертификат будет показан зеленым. Погуглите услуги extended validation certificate у публичных ЦС.
TrainIT Hard я помню что нужно поди создать политику в AD CS а потом в меню Extended Validation их добавить, делаем для EV Subordinate CA во все шаблоны политику и доп.поля и готово!
TrainIT Hard а только в каком меню я забыл
Я бы даже и 4 кб ключ посоветовал, различие в том, что ясно понятно что RSA-1024 не защищен, но для поиска ключа 2048 бит нужно найти 2 пары открытых и закрытых, а для поиска 4096 бит, тут уже будет очень не сильно просто, в рекомендации ECC-521 и DES-1024
EV никогда не делал - зачем он, если серт непубличный? :) По ключу можно и 4096, только не забываем про обратную совместимость - например старые циски не умели в ключи длиннее 2048.
Стоп! Я ещё смотрю видео. насчет цифровой подписи. как же пользователи узнаёт, что открытый ключ, который у него имеется, действительно принадлежит тому, Чьи данные он хотел бы получить?
Потому что, если он попытается расшифровать подпись чужим открытым ключом, у него ничего не выйдет, так как пара открытый-закрытый ключ математически взаимосвязана.
+TrainIT Hard
А если цифровая подпись поддельная, данные поддельные, и открытый ключ у меня не тот?
+Account Synchronization
Я так понимаю, это будет атака Man-in-the middle
То вы это поймете.
+TrainIT Hard
И как я это пойму?
Маленькая поправка: public key и private key математически не соотносятся.Эти ключи различны и не могут быть получено один из другого
Я и не говорил, что из одного ключа можно получить другой. Возможно только расшифровать сообщение зашифрованное другим ключом.
Публичный ключ формируется на основе приватного (по крайней мере в openssl). Если это не математическое соотношение, то что это? И сомнительно, что публичным ключом можно расшифровать сообщение, зашифрованное приватным ключом. Что же это получается? У всех есть публичный ключ сервера (на то он и публичный), и все (включая ФСБ) могут расшифровать то, что сервер шифрует приватным ключом и шлет исключительно Маше? Хуйня собачья. Публичный ключ используется только для шифрования. Далее только сервер может расшифровать это своим приватным ключом. И насколько я успел разобраться (отнюдь не благодаря этому видео), так браузер передает симметричный сессионный ключ, который он сгенерировал, и который будет использован в дальнейшем уже симметричном шифровании, т.к. асимметричное слишком вычислительно-затратное. Хотелось бы узнать, как работает сертификат, с помощью которого браузер убеждается, что человек посередине не подменил публичный ключ сервера, но, что-то подсказывает мне, что в этом говно-видео это вряд ли освещается.
Жаль, что не рассказал об отличиях SSL и TLS
Все, что нужно знать - SSL это древний протокол и сейчас почти нигде не используется. Все что сейчас называют SSL, на самом деле является TLS в 99% случаев.
@@TrainITHard Спасибо, буду знать :-)
15:14 HASH шифруется закрытым, а расшифровывает открытым 17:47
все верно, в чем вопрос?
Тогда какая тут безопасность, если открытый ключ может расшифровать то, что зашифровано закрытым? Ладно, вопрос безопасности пока не важно, потом сам разберусь, почитав что-нибудь)
Если вы внимательно смотрели урок, то могли понять что это принцип работы цифровой подписи,а не шифрования. :)
TrainIT Hard, вот тут момент объясните, плиз. Получается мы шифруем хэш закрытым ключем и отправляем. Хакер это перехватывает. Он сможет закрытый ключ извлечь из этого и потом перехватить и открытый, который свободно гуляет и расшифровывать вообще что угодно у этого пользователя?
it -eng Как это "хакер" сможет извлечь закрытый ключ? Функция от закрытого ключа уже применена к самими данным. Сам ключ то не передается)
46:05 всего 256 байт, а не 2 килобайта)
да про вланы бы очень хотелось узнать...
Действительно, что ты хочешь про них узнать? Здесь идеи криптография, а ты про вланы, ору)
@@w1tcherj ну объясните для начала раз так просто
@@sashashad а что тебе непонятно? Не лекцию же мне читать
@@w1tcherj мне не понятно как это прикручивается на уровне домена, как ьам выдаются acl
@@sashashad ты дурочок?
Ох
Ххххнх
Нхехееххх
Еженедельник же
Е
Ю
В аж
Я
Я
Я
Я
Я
Я
Я
Шифруется открытым ключём а расшифровывается закрытым.
иеп
Шифруем открытым ключем, а не наоборот.
Замечательный цикл, но я вижу не ключик на рисунки, а.. НЕ_КЛЮЧ. Простите. :-)
Все хорошо. Но только одно не понятно, зачем винда на английском и текст в примерах на английском?
Потому что в IT индустрии принято говорить на инглише
Чтобы зашифровать от вас важную информацию
С большим удивлением узнал что "ассиметричный" пишется c одной с
Лучше бы и не узнавал вовсе, потому что "асимметричный" пишется с двумя "м" а не "с".
🤣🤣🤣