У клиента на другой платформе при каждом изменении файла и шифровании будет использоваться одно и то же IV, и этого достаточно, чтобы ослабить стойкость шифрования: подробности можете посмотреть в первой ссылке моего изначального комментария, но как бы то, что злоумышленник может увидеть в каком блоке было изменение - это уже нехорошо.
По поводу AES CBC - главный недостаток, это то, что нет аутентификации, то есть злоумышленник может пытаться подменить шифротекст, поменяв какие-то биты, и смотреть, что получится. А если говорить про CBC, то может попытаться сделать padding oracle attack - а вы, наверняка, не тестировали, что будет, если в вашей реализации при расшифровке на вход передать неправильный padding.
Если выбирать из семейства AES, то почти всегда единственным безопасным алгоритмом будет AES GCM (если нет очень веских причин выбрать другой алгоритм) - но вы почему-то его вообще не рассматриваете. Если не из семейства AES, то с xchacha20-poly1305 сложнее накосячить. Но вообще правильное использование низкоуровневых криптографических библиотек - дело достаточное хитрое, и, чтобы не ошибиться ненароком, есть более высокоуровневые библиотеки типа NaCl/libsodium, используя которые можно избежать многих подводных камней.
По моему опыту (не Канада, Европа), не найти работу за два месяца - нормально. С отсутствием опыта работы в новой стране проживания я бы предположил, что найти работу за полгода - хорошо. Если по законодательству от компании требуется бюрократия или денежные вложения для оформления сотруднику визы/внж, то полгода - это даже очень хорошо.
По резюме, я не специалист в рекрутинге, но если бы я был hiring manager, то насторожился бы пересечению фриланса и работе по найму. И мне кажется, что сотруднику с опытом 7+ лет указывать образование Udemy - это подозрительно. Возможно Минского университета было бы достаточно (но опять же я не специалист в рекрутинге).
- Название модуля в go.mod: обычно оно не src, а github.com/blahblah/blahblahblah. Это имеет значение, если кто-то будет импортировать ваш код. И совсем не обязательно помещать весь код в src.
- Вы начали использовать пакет internal для кода, который не должен переиспользоваться вне проекта, но при этом по какой-то загадочной причине контроллер и роутер не попадают в internal. По-хорошему, практически весь код, кроме main, может (и должен) быть в internal.
- Я очень понимаю желание использовать DI-контейнеры после многолетнего опыта работы с .NET, но по сути для микросервисов (если они, конечно, микро) большой пользы они не приносят - достаточно просто построить дерево зависимостей вручную.
- Если уж использовать ООП, то зависимости контроллеров, роутеров итп должны быть от интерфейсов, а не от реализаций. Ну, и тестов нет :-( Зачем городить многослойность контроллер-сервис-репозиторий, если нет ни бизнес-логики, ни доменной модели, ни тестов? А если и делать многослойную архитектуру (с расчетом, что когда-то микросервис станет гигантским монолитом), то почему вдруг сервис зависит от моделей API?
- Зачем экспортировать все поля в структурах таких, как Router, ControllerRoute, Server?
- В методе CreateBook контроллера отсутствует обработка ошибок - ошибки попросту игнорируются, что нехорошо. То же в методе Run сервера, который по-хорошему должен был бы возвращать ошибку.
- В методе getEnvAsInt: код на Go читается гораздо удобнее, если сверху вниз - happy path, магистральный сценарий, а все if обрабатывают ошибочные ситуации. Если поменять инвертировать if err == nil, чтобы стало if err != nil, то код станет каноничнее.
У клиента на другой платформе при каждом изменении файла и шифровании будет использоваться одно и то же IV, и этого достаточно, чтобы ослабить стойкость шифрования: подробности можете посмотреть в первой ссылке моего изначального комментария, но как бы то, что злоумышленник может увидеть в каком блоке было изменение - это уже нехорошо.
По поводу AES CBC - главный недостаток, это то, что нет аутентификации, то есть злоумышленник может пытаться подменить шифротекст, поменяв какие-то биты, и смотреть, что получится. А если говорить про CBC, то может попытаться сделать padding oracle attack - а вы, наверняка, не тестировали, что будет, если в вашей реализации при расшифровке на вход передать неправильный padding.
Если выбирать из семейства AES, то почти всегда единственным безопасным алгоритмом будет AES GCM (если нет очень веских причин выбрать другой алгоритм) - но вы почему-то его вообще не рассматриваете. Если не из семейства AES, то с xchacha20-poly1305 сложнее накосячить. Но вообще правильное использование низкоуровневых криптографических библиотек - дело достаточное хитрое, и, чтобы не ошибиться ненароком, есть более высокоуровневые библиотеки типа NaCl/libsodium, используя которые можно избежать многих подводных камней.
Простите, несколько вопросов по используемой криптографии.
1) Я так понял вы один раз генерируете соль и IV, линкуете и они переиспользуются при каждом шифровании? Если это правда, то так делать нельзя. Например, вот почему: https://derekwill.com/2021/01/01/aes-cbc-mode-chosen-plaintext-attack/
2) А почему AES CBC, собственно? Ведь в нем же нет аутентификации. https://alicegg.tech/2019/06/23/aes-cbc
По моему опыту (не Канада, Европа), не найти работу за два месяца - нормально. С отсутствием опыта работы в новой стране проживания я бы предположил, что найти работу за полгода - хорошо. Если по законодательству от компании требуется бюрократия или денежные вложения для оформления сотруднику визы/внж, то полгода - это даже очень хорошо.
По резюме, я не специалист в рекрутинге, но если бы я был hiring manager, то насторожился бы пересечению фриланса и работе по найму. И мне кажется, что сотруднику с опытом 7+ лет указывать образование Udemy - это подозрительно. Возможно Минского университета было бы достаточно (но опять же я не специалист в рекрутинге).
Я вот тоже когда-то переходил из .NET в Go.
Несколько случайных замечаний:
- Название модуля в go.mod: обычно оно не src, а github.com/blahblah/blahblahblah. Это имеет значение, если кто-то будет импортировать ваш код. И совсем не обязательно помещать весь код в src.
- Вы начали использовать пакет internal для кода, который не должен переиспользоваться вне проекта, но при этом по какой-то загадочной причине контроллер и роутер не попадают в internal. По-хорошему, практически весь код, кроме main, может (и должен) быть в internal.
- Я очень понимаю желание использовать DI-контейнеры после многолетнего опыта работы с .NET, но по сути для микросервисов (если они, конечно, микро) большой пользы они не приносят - достаточно просто построить дерево зависимостей вручную.
- Если уж использовать ООП, то зависимости контроллеров, роутеров итп должны быть от интерфейсов, а не от реализаций. Ну, и тестов нет :-( Зачем городить многослойность контроллер-сервис-репозиторий, если нет ни бизнес-логики, ни доменной модели, ни тестов? А если и делать многослойную архитектуру (с расчетом, что когда-то микросервис станет гигантским монолитом), то почему вдруг сервис зависит от моделей API?
- Зачем экспортировать все поля в структурах таких, как Router, ControllerRoute, Server?
- В методе CreateBook контроллера отсутствует обработка ошибок - ошибки попросту игнорируются, что нехорошо. То же в методе Run сервера, который по-хорошему должен был бы возвращать ошибку.
- В методе getEnvAsInt: код на Go читается гораздо удобнее, если сверху вниз - happy path, магистральный сценарий, а все if обрабатывают ошибочные ситуации. Если поменять инвертировать if err == nil, чтобы стало if err != nil, то код станет каноничнее.
Удачи!