Безопасный сокет против шифрования данных

Question

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

У меня есть два варианта:

1- Безопасный сокет
- Открыть безопасный сокет
- Записать чистые данные

2 - Сокет
- Открыть сокет
- Зашифровать данные
- Записать зашифрованные данные

Есть ли преимущество в производительности при использовании защищенного сокета вместо «обычного» сокета, в который я записываю зашифрованные данные?(допустим, я использую один и тот же шифр в обоих случаях)

Answer 1

(Обратите внимание, что безопасный сокет без аутентификации позволяет человеку в середине (MITM) перехватывать и, таким образом, ясно видеть ваши данные.)

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

Однако, если у вас нет предварительного общего ключа, рукопожатие - это то, чего вы не должны избегать.

Answer 2

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

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

Так что проверьте самый быстрый TLS1.2 или 1.3 ciphersuites и использовать это.Вы можете проверить, что Google представил в TLS;они действительно сосредоточены на скорости и безопасности.