Асимметричное шифрование (шифрование с открытым ключом) Мне нужно разъяснение

Question

Я искал ЧАСЫ о том, как это работает, и я просто не могу понять, как это может быть. Единственные данные определения состоят в том, что зашифрованное сообщение с открытым ключом может быть расшифровано только с помощью закрытого ключа. Для меня это просто глупость, и я объясню.

Веб-сайт должен быть загружен вашим браузером, что также означает, что сценарии Javascript и все остальные материалы доступны любому, кто ловит ваш сайт, если он тоже этого захочет. Это также означает, что теперь этот человек знает, как вы вычисляете свои вещи с помощью вашего открытого ключа, делая возможным БЕЗ закрытого ключа для его расшифровки.

Я просто пытаюсь выяснить, как это работает, и для меня не имеет смысла, что вы НЕ МОЖЕТЕ дешифровать зашифрованный текст с открытого ключа, когда у вас есть доступ ко всем вычислениям, сделанным со стороны, которую он зашифровал.

Я имею в виду, когда вы отправляете пароль, например, сначала, на СВОЕМ конце, на стороне браузера, он шифрует данные, которые будут получены сервером. Зашифровывая данные со стороны браузера, любой, кто взглянул на ваш исходный код, может узнать, как вы его зашифровали, и теперь его можно использовать для расшифровки. Я создаю новую систему шифрования для нашего веб-сайта, где сервер случайным образом создает ключ сеанса, который может использоваться только пользователем с соответствующим сеансом. Таким образом, только 2 компьютера могут общаться друг с другом с помощью одного и того же ключа, поэтому, если вы используете один и тот же ключ на другом компьютере, он просто не будет работать, так как каждый ключ сохраняется для каждого сеанса, который ключ умирает через определенное время. С того, что я прочитал, эти швы можно назвать системой симметричного ключа. Я хочу попробовать и запрограммировать свою собственную систему ассиметричных ключей, но во всех случаях, когда я читаю, я могу только выяснить, что независимо от того, что происходит как шифрование на стороне клиента, если злоумышленник перехватывает непосредственно перед отправкой информации, он имеет доступ к тому, как шифрование работает и для этого, не нуждается в закрытом ключе на стороне сервера, поскольку ему просто нужно повернуть процесс вспять, зная, как это было сделано на стороне клиента.

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

Я добавлю немного больше информации, так как думаю, что мы не совсем поняли, что я имею в виду. При отправке пароля произнесите мое имя «Дэвид» и назовем нашего пользователя WebUser. Мы назовем нашего вредоносного пользователя BadGuy. Таким образом, BadGuy позволяет интегрироваться между WebUser и его браузером. BadGuy также получает ВСЕ javascript-коды веб-страницы, позволяющие ему видеть, как вычисления работают, прежде чем они будут отправлены. WebUser вводит свой пароль «David», который передается в систему шифрования javascript. С самого начала BadGuy не нужно ничего расшифровывать, так как он уже поймал пароль. НО, когда веб-сайт отвечает, BadGuy выполняет все расчеты и может использовать полученные зашифрованные данные и расшифровать их, используя расчеты дешифрования, которые он может видеть в полученном коде веб-страниц.

Итак, единственное, что я могу понять, это то, что ассиметричные ключи используются для шифрования, которое технически дешифруемо с использованием общеизвестных известных чисел. Но в случае RSA эти 2 числа настолько велики, что понадобятся годы, чтобы выяснить известный расшифровщик. Как я могу также недооценивать, это то, что намного проще создать 2 числа из частного номера. Но в любом случае процесс шифрования обычно заканчивается общим временным интимным ключом между двумя сторонами для более быстрой связи, и никто не может предотвратить BagGuy между пользователем и браузером, но с современными технологиями, настоящая угроза - это больше атак MiTM, где один будет нюхать сеть. Во всех случаях не существует определенного способа передачи 100% данных в незашифрованном виде, поскольку как минимум 50% из них являются дешифруемыми, т.е. данные, поступающие с одной стороны, или данные, отправляемые на другую сторону.

Answer 1

расширение предыдущего ответа

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

Волшебство здесь называется Обмен ключами DH .

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

Любая «слушающая» сторона (ваш BadGuy) не сможет получить ключ сеанса, даже прослушивая все сообщения. Сервер будет использовать свой сертификат и закрытый ключ, чтобы обеспечить связь клиента с законной целью. Это мешает активному «человеку посередине» выдавать себя за фальшивый сервер.

не имеет смысла, что вы НЕ МОЖЕТЕ дешифровать зашифрованный текст с открытого ключа, когда у вас есть доступ ко всем вычислениям, сделанным со стороны, которую он зашифровал.

Асимметричная криптография основана на так называемых функциях «люка». Это означает, что функцию легко вычислить одним способом (например, зашифровать данные), но очень трудно (не выполнимо) определить ее противоположным образом без какого-либо секретного значения (личного ключа). Действительно, иногда это трудно понять, и существует множество ограничений, связанных с тем, что асимметричное шифрование действительно безопасно. Вот почему вы всегда пользуетесь какой-нибудь доверенной библиотекой, чем сами.

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

Не без случайного секретного ключа, который получается между клиентом и сервером во время обмена ключами (см. Первый абзац).

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

Это одно из правил в области криптографии - не создавайте свою собственную криптографию!

Обычно это плохая идея. Обратите внимание, что используемые в настоящее время безопасные каналы (SSL, TLS, .. на основе RSA , ECC ) разработаны, проверены и используются многими умными людьми, которые знают, что делают Как смягчить различные векторы атаки. И имхо это еще не идеально, но это лучшее, что у нас есть.

Answer 2

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

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

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

Рассмотрим пример управления версиями. Вы участвуете в проекте с некоторыми членами команды. Когда вы извлекаете коммиты других, он зашифровывается вашим открытым ключом, поэтому, как только он будет загружен на вашем конце, вы сможете расшифровать его через свой закрытый ключ. По мере того, как вы работаете и делаете свои коммиты, вы помещаете изменения в репозиторий, зашифрованные с помощью вашего закрытого ключа. Другая сторона сообщения уже имеет ваш открытый ключ и сможет его расшифровать. Важно, чтобы вы никому не передавали свой закрытый ключ, поэтому ваши товарищи по команде не смогут выдать себя за вас, передавая вредоносный код на ваше имя. Вы можете поделиться своим открытым ключом с кем угодно, но рекомендуется делиться им только с доверенными лицами, такими как ваши товарищи по команде, чтобы никто другой не смог расшифровать что-либо, зашифрованное вашим личным ключом.

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

Идентификатор сеанса - это значение, которое идентифицирует сеанс. Если существует только одно такое значение, то это не ассиметричное шифрование, так как не задействованы открытый и закрытый ключи, и как только кто-то украл идентификатор сеанса, как вы правильно указали, злоумышленник / система может выдать себя за действительного пользователя и делать гадости. Итак, проблема, которую вы определили, на самом деле существует, но это не новая проблема, и решения были реализованы. Решение, которое вы ищете, - HTTPS. Как только ваш сайт получит соответствующий сертификат, вы сможете использовать ассиметричное шифрование в целости и сохранности. Под капотом у сервера будет открытый ключ сеанса пользователя, в то время как пользователь будет использовать закрытый ключ для шифрования / дешифрования, и если посредник перехватывает открытый ключ сеанса (который не является идентификатором сеанса), злонамеренный третье лицо не сможет выдать себя за действительного пользователя. Подробнее здесь:

https://en.wikipedia.org/wiki/Transport_Layer_Security