В соответствии с CWE-329 NON-Random IV допускают возможность атаки по словарю. Однако in the AES crypto example, golang документы используют неслучайный IV:Почему в примере golang crypto не используется случайный IV?
ciphertext := make([]byte, aes.BlockSize+len(plaintext))
iv := ciphertext[:aes.BlockSize]
Является ли это реализация безопасной или я должен использовать случайную функцию, чтобы получить мой IV?
Это безопасно, потому что IV заполняется из криптографически безопасного генератора псевдослучайных чисел (CSPRNG), который по умолчанию является /dev/urandom и предоставляется из ОС. Из функции ExampleNewCBCEncrypter:
iv := ciphertext[:aes.BlockSize]
if _, err := io.ReadFull(rand.Reader, iv); err != nil {
panic(err)
}
Ваше первое предложение неверно. 'make' всегда возвращает обрезанный срез. 'enciphertext' всегда будет равным нулю в примере OP. –
100% этого неправильно. Если емкость не предоставляется при создании среза, то она совпадает с длиной. Независимо от того, предоставлено ли оно или нет, не имеет никакого отношения к инициализации базового массива; он всегда инициализируется нулями. – hobbs
Вы не можете получить доступ к неинициализированной памяти в Go без использования «небезопасных». – JimB
Вы ошибаетесь. В случае шифрования используется случайный IV. В случае дешифрования используется сообщение IV из сообщения. Не позволяйте факту, что ИВ инициализируется как фрагмент зашифрованного текста, обманите вас; следующая вещь, которую он делает, - это считывание случайных байтов в этот фрагмент из [сильного случайного источника] (http://golang.org/pkg/crypto/rand/#pkg-variables). – hobbs
Благодарим вас за разъяснения относительно примера GO, который действительно рандомизирует IV, выполнив 'io.ReadFull (rand.Reader, iv)'. Я думаю, что это немного вводит в заблуждение. Выполнение 'iv: = make ([] byte, [: aes.BlockSize])' назначение будет более четким. – Vinzent
это даже не действительный синтаксис. – hobbs