Go кораблі з повним набором криптографічних пакетів в стандартній бібліотеці, щоб допомогти розробникам будувати безпечні додатки. завершити аудит основного набору пакетів, які також підтверджуються як частина Аудит привів до єдиного висновку низької серйозності, в спадковому і незахищеному вигляді. , а також декілька інформаційних висновків. повний текст аудиторського звіту можна знайти . Шляхи біт Новий модуль FIPS 140-3 Go+BoringКриптоінтеграція Тут Обсяг аудиту включав наші реалізації ключових обмінів (ECDH і пост-квантовий ML-KEM), цифрового підпису (ECDSA, RSA, і Ed25519), шифрування (AES-GCM, AES-CBC, і AES-CTR), хешінг (SHA-1, SHA-2, і SHA-3), ключове походження (HKDF і PBKDF2), а також аутентифікацію (HMAC), а також криптографічний генератор випадкових чисел. Включені низькорівні впровадження великих цільних і еліптичних кривих з їх чутливими ядрами монтажу. Протоколи вищого рівня, такі як TLS і X.509, не були в межах застосування. Ми пишаємося даними про безпеку пакетів криптографії Go, а також результатами цього аудиту, який є лише одним з багатьох способів отримання впевненості у правильності пакетів. які, наприклад, надають пріоритет безпеці над продуктивністю. Ми робимо ставку на використання безпечних API навіть для внутрішніх пакетів, і, звичайно, ми можемо покладатися на властивості мови Go, щоб уникнути проблем з управління пам'яттю. Принципи криптографії Потрібно ретельно перевірити їх Виявлення низької серйозності Єдиний потенційно використана проблема, TOB-GOCL-3, має Це означає, що він мав незначний вплив і був важко викликати. Низька серйозність Наступна статтяКільцева гімнастика ( Управління пам'яттю в , який не ввімкнений за замовчуванням і не підтримується для використання поза межами Google. Детальніше обговорюється нижче Створення Go+BoringCrypto GOEXPERIMENT 5 Інформаційні результати Решта висновків є , що означає, що вони не становлять безпосереднього ризику, але мають відношення до найкращих практик безпеки. інформаційна Висновки TOB-GOCL-1, TOB-GOCL-2 і TOB-GOCL-6 стосуються можливих побічних каналів часу в різних криптографічних операціях. З цих трьох висновків тільки TOB-GOCL-2 впливає на операції, які, як очікувалося, будуть постійними в часі через функціонування на секретних значеннях, але це впливає тільки на цілі Power ISA (GOARCH ppc64 і ppc64le). TOB-GOCL-4 підкреслює ризик зловживання в внутрішньому API, якщо він буде повторно використаний за межами його поточного випадку використання. TOB-GOCL-5 вказує на відсутність перевірки за межею, яку неможливо досягти. Тимчасові канали Висновки TOB-GOCL-1, TOB-GOCL-2 і TOB-GOCL-6 стосуються дрібних бічних каналів часу. TOB-GOCL-1 і TOB-GOCL-6 пов'язані з функціями, які ми не використовуємо для чутливих значень, але можуть бути використані для таких значень в майбутньому, а TOB-GOCL-2 пов'язаний з монтажною реалізацією P-256 ECDSA на Power ISA. : перетворення від байтів до елементів поля не є постійним часом (TOB-GOCL-1) crypto/ecdh,crypto/ecdsa Внутрішнє впровадження еліптичних кривих NIST забезпечило метод перетворення елементів поля між внутрішніми та зовнішніми представленнями, що працювали у змінний час. Всі використання цього методу працювали на публічних входах, які не вважаються секретними (публічні значення ECDH і публічні ключі ECDSA), тому ми визначили, що це не проблема безпеки. , щоб запобігти випадковому використанню цього методу в майбутньому з таємними цінностями, і щоб нам не довелося думати про те, чи є це проблемою чи ні. Зробіть метод постійним часом у будь-якому випадку P-256 умовне заперечення не є постійним часом в установці Power ISA (TOB-GOCL-2, CVE-2025-22866) crypto/ecdsa Поза цим , Go також підтримує ряд додаткових платформ, включаючи деякі менш поширені архітектури. Під час перегляду наших монтажних реалізацій різних основних криптографічних примітивів, команда Trail of Bits виявила одну проблему, яка вплинула на реалізацію ECDSA на архітектурах ppc64 та ppc64le. Перший клас платформ Завдяки використанню умовної інструкції розгалуження при реалізації умовного заперечення точок P-256 функція працювала в змінному часі, а не в постійному часі, як очікувалося. з шаблоном, який ми вже використовуємо в інших місцях, щоб умовно вибрати правильний результат в постійному часі. ми присвоїли цю проблему CVE-2025-22866. Заміна інструкції умовного розгалуження Щоб надати пріоритет коду, який досягає більшості наших користувачів, і через спеціалізовані знання, необхідні для цілеспрямованості конкретних МСА, ми зазвичай покладаємося на внески спільноти для підтримки монтажу для платформ, які не є першим класом. : Scalar.SetCanonicalBytes не є постійним часом (TOB-GOCL-6) crypto/ed25519 Внутрішній пакет edwards25519 забезпечив метод перетворення між внутрішнім і зовнішнім представленням скалярів, які працювали в змінний час. Цей метод використовувався тільки для підпису входів для ed25519.Verify, які не вважаються секретними, тому ми визначили, що це не проблема безпеки. , щоб запобігти випадковому використанню цього методу в майбутньому з таємними значеннями, і тому що ми знаємо, що люди вишивають цей код поза стандартною бібліотекою, і можуть використовувати його з таємними значеннями. Зробіть метод постійним часом у будь-якому випадку Cgo Меморіальний менеджмент Виявлення TOB-GOCL-3 стосується проблеми управління пам'яттю в інтеграції Go+BoringCrypto. : індивідуальний фіналізатор може звільнити пам'ять на початку виклику функції C за допомогою цієї пам'яті (TOB-GOCL-3) crypto/ecdh Під час огляду було поставлено ряд питань щодо нашої інтеграції Go+BoringCrypto на базі cgo, яка забезпечує режим шифрування відповідно до FIPS 140-2 для внутрішнього використання в Google. Команда Trail of Bits виявила одну вразливість і одну Оскільки команда Go не підтримує використання цього коду поза межами Google, ми вирішили не видавати запис бази даних уразливості CVE або Go для цієї проблеми, але ми . Небезпечний bug Зробити це можна в 1.24 Цей вид пастки є однією з багатьох причин, чому ми вирішили відступити від інтеграції Go+BoringCrypto. що використовує звичайні пакети чистої криптографії Go, що дозволяє нам уникнути складної семантики cgo на користь традиційної моделі пам'яті Go. Натуральний режим FIPS 140-3 Комплексність реалізації Висновки TOB-GOCL-4 та TOB-GOCL-5 стосуються обмеженої реалізації двох специфікацій, та . Новий NIST SP 800-90A РФК 8018 API CTR_DRBG представляє кілька ризиків неправильного використання (TOB-GOCL-4) crypto/internal/fips140/drbg Як частина Для того, щоб забезпечити відповідну випадковість, нам потрібно було впровадити NIST CTR_DRBG (детерміністичний генератор випадкових бітів на основі AES-CTR). Натуральний режим FIPS 140-3 Оскільки для наших цілей нам потрібен лише невеликий підсумок функціональності NIST SP 800-90A Rev. 1 CTR_DRBG, ми не реалізували повну специфікацію, зокрема, випускаючи функцію походження та струни персоналізації. Оскільки наша реалізація тісно розмежована на конкретний випадок використання, який нам потрібен, і оскільки реалізація не експортується публічно, ми визначили, що це прийнятно і варте зменшення складності реалізації. Детальніше про ці обмеження. Додати попередження до документації PBKDF2 не застосовує обмеження довжини виходу (TOB-GOCL-5) crypto/pbkdf2 У Go 1.24 ми почали процес переміщення пакетів з Завершуючи плутанину, перша сторона, високоякісні і стабільні пакети Go-криптографії залишалися поза стандартною бібліотекою без особливої причини. Голанг.орг/x / криптовалюта В рамках цього процесу ми перенесли Під час перегляду цього пакету команда Trail of Bits помітила, що ми не застосовували обмеження на розмір похідних ключів, визначених у . golang.org/x/криптовалюта/pbkdf2 РФК 8018 Ліміт є При використанні SHA-256, перевищення ліміту займе ключ більше 137 ГБ. Ми не очікуємо, що хтось коли-небудь використовував PBKDF2 для створення такого великого ключа, особливо тому, що PBKDF2 виконує ітерації на кожному блоці, але заради коректності, ми . (2^32 - 1) * <hash length> Застосовується в межах, визначених стандартом Що буде далі Результати цього аудиту підтверджують зусилля, вкладені командою Go у розробку високоякісних, простих у використанні бібліотек криптографії, і повинні забезпечити впевненість наших користувачів, які покладаються на них для створення безпечного та безпечного програмного забезпечення. Однак ми не відпочиваємо на своїх лаврах: вкладники Go продовжують розвивати та вдосконалювати криптографічні бібліотеки, які ми надаємо користувачам. Go 1.24 тепер включає режим FIPS 140-3, написаний в чистому Go, який в даний час проходить тестування CMVP. Це забезпечить підтримуваний режим відповідності FIPS 140-3 для всіх користувачів Go, замінюючи інтеграцію Go+BoringCrypto, яка наразі не підтримується. Ми також працюємо над впровадженням сучасної пост-квантової криптографії, вводячи ML-KEM-768 і ML-KEM-1024 у Go 1.24 у програмі. , і додавання підтримки пакету crypto/tls для гібридного ключового обміну X25519MLKEM768 . Пакет криптовалюти / mlkem Нарешті, ми плануємо запровадити нові, більш зручні для використання API криптографії високого рівня, призначені для зменшення бар'єру для вибору та використання високоякісних алгоритмів для базових випадків використання. Ми плануємо почати з запропонування простого API хешування паролів, який усуває необхідність для користувачів вирішувати, на який з безлічі можливих алгоритмів вони повинні покладатися, з механізмами автоматичної міграції до новітніх алгоритмів під час найсучасніших змін. Роланд Шумейкер і Філіппо Валсорда Ця стаття доступна на сайті The Go Blog під ліцензією CC BY 4.0 DEED. Блог Go Блог Go Фото Batyrkhan Shalgimbekov на Unsplash Батирхан Шальгімбеков Unsplash

Try and Download Go 

Read My Stories

Це аудіо створено мовою оригіналу історії!

Пакети криптографії Go були перевірені: результати

About Author

КОМЕНТАРІ

ПОВІСИТИ БИРКИ

ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps