mayton2019

Но если, допустим, два человека ведут беседу в текстовом чате, а во время обмена публичными ключами, "по середине" незаметно вторгнется еще один человек (MITM - Man In The Middle)

Давай в этой схеме я выброшу двух людей. И заменю их на браузер и сайт. Там на самом деле и просиходит такой-же чат. Браузер спрашивает и сайт отвечает. Так вот. Эта схема защищена цифровыми сертификатами. И центром сертификации. Тоесть еще до того как вы начали хоть какой-то обмен работают протоколы установки соединения по TLS/SSL когда браузер может удостоверится что центр сертификации одобрил одного из людей и подтвердил его личность. Это Боб проверяет что Алиса - это действительно Алиса. И также получает ее public key который вобщем-то публичен и тоже является частью сертификата.

Вот придумай где подпихнуть твоего человека-Кларка посередине.

Я слышал про "квантовое шифрование", но это уже следующий век.

Квантового шифрования не существует. Есть алгоритм быстрог разложения длинного числа на множители который является частью протоколов RSA. Но все успехи в науч-попе пока ограничены тем что создали комп очень малой разрядности который и близко не подошел к нужным границам и комп сам представляет собой физ-лабораторию с криогеном и защитой от всеговсего. И нет даже надежды что такой комп вставят в телефон или десктоп. Физика - здесь наука злая и циничная. Более того даже если будут успехи в этой области у КК - то у нас в запасном кармане есть эллиптическая криптография EDSA на которую пока еще ничего не придумано. Поэтому насчет КК и криптографии нам можно вообще не беспокоиться. И нашим детям тоже. И внукам.

Кстати я вижу что qna.habr для меня использует алгоритм EDSA + SHA256

Rust создавался при разработке браузера Mozilla чтобы закрыть конкретные дефекты С++. Системообразующие дефекты такие как NPE, Buffer Overflow e.t.c. Сегодня доля Rust файлов в сорцах мозиллы составляет 40% от общего количества файлов. Это - достаточно чтобы считать успехом мероприятие.

Нужно ли брать Rust при разработке игровых движков? ХЗ. Я-бы сказал что Rust важнее для тех приложений где важна инфо-безопасность. Я не спец в Rust, но я чисто из любопытва смотрел например как в Rust открыть файл (мне надо было парсить логи). Так вот открыв файл ты не просто не получаешь файловую переменную. Ты получаешь монаду Either (там кажется она называется Result<>) и вот пока ты ее паттерн матчингом не проверишь - никакого файла не получишь. Тоесть протокол работы с файлами строгий настолько, насколько это возможно. Срезать поворот - не получается. Это в сях можно взять fopen(..) и результат проe..ать.

Вобщем rust по уровню строгости напоминает... ну не знаю Haskell наверное. Хотя в Rust тоже можно творить безпредел - но по крайней мере ты будешь явно декларировать операции как usafe. Это слишком очевидно вобщем-то. Дело техники на code-review просто отделить опасное и принять решение стоит ли так кодить или нет.

Да и один финский парень обещал что в Rust скоро зайдет как второй язык разработки ядра Linux. Ждем пока.

А распечатай чему равно month.

System.out.println("Input = " + month);

Да, можно. Вот константа Math.PI захардкожена в библиотеке математики и ни у кого не возникает с этим вопросов.

По поводу констант в Dagger2. Я с ним 1 раз поработал на проекте Java/AWS/lambda стека. Для простых проектов где требуется инжекторный двигатель, но Spring затаскивать - лениво, Dagger - самое то.

По поводу допустимо или нет - да допустимо. Тем более что ты пишешь что "один раз на проект". Вот к примеру имя таблицы. Ну кому в голову придет его менять? Это объем работ на самом деле в сто крат более тяжелый. И даже не в Даггере дело а в том что таблица к тому времени станет слишком родной для environment и дешевле будет поднять новую таблицу чем переименоввать старую. Уж повертье так оно бывает.

Передавать через конструктор или нет? Смотри если для модульных тестов тебе надо их менять - то передавай через конструктор. Если тесты не нужны на эту компоненту - то делай как проще.

Про константу PI конечно была шутка но в проекте есть два зла. Первое зло - заиграться в конфигурации и любой пустяк через них протаскивать. И второе зло - сделать проект неконфигурируемым. Я думаю что хороший проект - стоит где-то посередине.

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

Другое дело что основному процессору придется какой-то процент своих ресурсов тратить на работу симметричных алгоритмов.