Цей виклик приносить велику суму в 200 балів за першу відповідь і залишається непереможеним принаймні 3 дні.Заявлений user3080953 .
Останнім часом багато говорять про шифрування в кінці та про тиск на компанії, щоб вилучити їх із своїх продуктів. Мене не цікавлять права та несправедливості цього, але я задумався: наскільки короткий код може бути таким, що на компанію тиснуть, щоб не використовувати його?
Завдання полягає в тому, щоб здійснити обмін ключами Diffie Hellman між двома мережевими системами, а потім дозволити користувачам спілкуватися вперед-назад за допомогою створеного симетричного ключа. Для цього завдання не потрібно застосовувати інших захистів (наприклад, не потрібно перемикати ключ, перевіряти особи, захищати від DoS тощо), і ви можете припустити відкритий Інтернет (будь-які порти, які ви слухаєте, доступні для всіх). Використання вбудованих дозволено та заохочується!
Ви можете вибрати одну з двох моделей:
- Сервер і клієнт: клієнт підключається до сервера, тоді сервер або клієнт можуть надсилати повідомлення іншому. Сторонні сторони між ними не повинні читати повідомлення. Приклад потоку може бути:
- Користувач A запускає сервер
- Користувач B запускає клієнта і направляє його на сервер користувача A (наприклад, через IP / порт), програма відкриває з'єднання
- Програма Користувача A підтверджує з'єднання (необов'язково спочатку просити користувача про згоду)
- Програма користувача B починає генерувати секрет DH та надсилає необхідні дані (відкритий ключ, праймер, генератор та все, що потрібно для вашої реалізації) Користувачеві A
- Програма Користувача A використовує надіслані дані для завершення генерації загальної таємниці та повертає необхідні дані (відкритий ключ) Користувачу B. З цього моменту Користувач A може вводити повідомлення (наприклад, через stdin), які будуть зашифровані та відправлені Користувачеві B (наприклад, до stdout).
- Програма користувача B завершує генерацію загального секрету. З цього моменту Користувач B може надсилати повідомлення Користувачеві А.
- Або: Сервер з двома підключеними до нього клієнтами: кожен клієнт спілкується з сервером, який пересилає своє повідомлення іншому клієнту. Сам сервер (і будь-які треті сторони між ними) повинні бути нездатні читати повідомлення. Окрім початкового з'єднання, процес такий же, як описаний у першому варіанті.
Детальні правила:
- Ви можете надати одну програму або кілька програм (наприклад, сервер і клієнт). Ваш бал - це загальний розмір коду для всіх програм.
- Ваша програма повинна теоретично вміти спілкуватися по мережі (але для тестування, localhost чудово). Якщо ваша обрана мова не підтримує мережу, ви можете комбінувати її з тим, що є (наприклад, сценарій оболонки); у цьому випадку ваш бал - це загальний розмір коду для всіх використовуваних мов.
- Генерація ключів Diffie Hellman може використовувати жорстко кодовані значення "p" та "g".
- Створений загальний ключ повинен бути не менше 1024 біт.
- Після того, як ключ розділений, вибір шифрування симетричного ключа залежить від вас, але ви не повинні вибирати метод, який, як відомо, має практичну атаку на нього (напр., Зсув кесаря є тривіальним, щоб повернути назад без знання ключа ). Приклад дозволених алгоритмів:
- AES (будь-якого розміру ключа)
- RC4 (теоретично зламаний, але ніяких практичних атак, про які я можу знайти згадку, тому це допустимо тут)
- Користувачі A і B повинні бути в змозі надсилати повідомлення один одному (двостороннє спілкування) в інтерактивному режимі (наприклад, читання рядків з stdin, постійне спонукання або такі події, як натискання кнопки). Якщо це полегшиться, ви можете взяти на себе чергування (тобто після того, як користувач надсилає повідомлення, вони повинні чекати відповіді, перш ніж надсилати наступне повідомлення)
- Мова вбудовані команди НЕ допускаються (немає необхідності писати свої власні криптографічні або мережеві методи , якщо вони вже підтримуються).
- Базовий формат спілкування залежить від вас.
- Наведені вище кроки спілкування є прикладом, але вам не потрібно дотримуватися їх (доки потрібна інформація буде надана, і жоден посередник не зможе обчислити спільний ключ або повідомлення)
- Якщо деталі, необхідні для підключення до вашого сервера, не відомі заздалегідь (наприклад, якщо він прослуховується на випадковому порту), ці дані повинні бути надруковані. Можна припустити, що IP-адреса машини відома.
- Поводження з помилками (наприклад, недійсні адреси, втрачені з'єднання тощо) не потрібно.
- Завдання - це гольф з кодом, тому виграє найкоротший код у байтах.
p
іg
дозволив?