Детерминированный выбор ключа с использованием итеративного сравнения значений — насколько это глупо?

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

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

Мы столкнулись с интересной проблемой при разработке способа обмена общим секретом после выполнения рукопожатия RSA. Поскольку эта крошечная программа не работала с концепцией клиент/сервер, нам нужен был способ гарантировать, что обе стороны выберут один и тот же ключ. Изначально я исследовал готовую реализацию ECC+Diffie-Hellman (из .NET), но обнаружился фатальный недостаток — класс работал только на Windows, а мой друг на Mac.

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

1. Оба одноранговых узла отправляют друг другу только что сгенерированный ключ (в частности, массив байтов ключа AES).
2. Оба одноранговых узла передают свой ключ и ключ своего партнера в алгоритм, который последовательно перебирает значения байтов (я думаю, как неявно преобразованные 8-битные целые числа?) в обоих массивах ключей.
3. Если один ключ имеет большее значение, чем другой в определенном индексе, этот ключ возвращается как выбранный ключ.
4. Если это условие ни разу не выполняется во время итерации, то ключи идентичны и не имеет значения, какой из них возвращается. (IV присутствовали, но были проигнорированы.)

Этот халтурный алгоритм из десяти строк работал намного лучше, чем имел право. С моим ограниченным пониманием математики это имеет смысл с точки зрения вычислений - есть $256^{32}$ возможные ключи и $\фракция{255}{256}$ шанс получить результат за (чрезвычайно дешевое) сравнение, так что вам практически гарантирован мгновенный полезный результат.

Тем не менее, мне все еще любопытно - как выглядит этот алгоритм с точки зрения безопасности? Если я чему-то и научился, просматривая этот SE, так это тому, что даже самые простые/безобидные вещи для неспециалиста вроде меня могут представлять собой вопиющие дыры в безопасности.

(Кроме того, я клянусь, что это никогда не будет использовано для чего-то важного. Теперь я знаю о Надувном замке, слава Богу.)

В отличие от Диффи-Хеллмана, это не препятствует пассивному прослушиванию. Злоумышленник, перехватывающий сетевой трафик, получит «свежие сгенерированные ключи», которые «отправляют оба узла» на шаге 1, и может применить алгоритм шагов 2/3/4, чтобы найти общий ключ, который в конечном итоге шифрует последующий трафик.