Какие требования по шифрованию данных существуют

Что проверяют

Различаете ли вы шифрование при передаче, шифрование при хранении и хеширование, и умеете ли сделать это в Go стандартными средствами, без самодельной криптографии. Следом обычно спрашивают, где у вас лежат ключи и как их ротировать.

Как отвечать

Требования приходят из двух мест: стандарты и регуляторы (PCI DSS для данных карт, 152-ФЗ для персональных данных в России, GDPR в Европе) и модель угроз самого сервиса. Дальше разложите по слоям:

• при передаче: TLS не ниже 1.2, лучше 1.3, на внешних и внутренних соединениях. В Go это crypto/tls и tls.Config с явным MinVersion, внутри кластера часто mTLS. InsecureSkipVerify: true в проде недопустим;
• при хранении: AES-256 в режиме с аутентификацией, то есть GCM. В Go: aes.NewCipher, затем cipher.NewGCM, nonce из crypto/rand, который никогда не повторяется с тем же ключом. Плюс шифрование дисков и бэкапов на уровне инфраструктуры;
• пароли: их не шифруют, а хешируют медленной функцией с солью: bcrypt или Argon2id из golang.org/x/crypto. SHA-256 и тем более MD5 для паролей не годятся, они слишком быстрые;
• ключи: не в коде и не в репозитории. KMS или Vault, схема envelope encryption (данные шифруются ключом данных, а он сам мастер-ключом), ротация и аудит доступа.

Асимметричная криптография (RSA, ECDSA, Ed25519) нужна для обмена ключами и подписей, большие объёмы данных ею не шифруют.

Где спотыкаются

Называют хеширование видом шифрования. Хеш необратим, поэтому и подходит для паролей, а обратимое шифрование паролей как раз ошибка.

Берут режимы без аутентификации вроде ECB или голый CBC. ECB сохраняет структуру данных, а CBC без MAC позволяет незаметно подменить шифртекст.

Путают источники случайности: math/rand вместо crypto/rand для nonce и токенов делает их предсказуемыми.