Пашырэнні інструкцый SHA
Таксама называецца SHA
Арыгінальнае пашырэнне x86 SHA паскарае асобныя аперацыі, якія выкарыстоўваюцца ў SHA-1 і SHA-256. Агульная пазнака функцыі SHA не гарантуе апаратнай падтрымкі кожнага алгарытму SHA.
Што вам трэба ведаць
Арыгінальнае пашырэнне x86 SHA паскарае асобныя аперацыі, якія выкарыстоўваюцца ў SHA-1 і SHA-256. Агульная пазнака функцыі SHA не гарантуе апаратнай падтрымкі кожнага алгарытму SHA.
Як гэта працуе
Арыгінальнае пашырэнне забяспечвае інструкцыі для раскладу паведамленняў і раундавай апрацоўкі для SHA-1 і SHA-256. Праграмнае забеспячэнне па-ранейшаму выконвае дапаўненне, кіраванне блокамі і поўную пабудову хэша. SHA-256 належыць да SHA-2, але SHA-512 і SHA-3 маюць іншыя алгарытмы, і іх наяўнасць нельга выводзіць з арыгінальнага біта функцыі.
Дзе гэта карысна
Бібліятэка хэшавання можа выбраць спецыялізаваную працэдуру сціскання SHA-256, калі пашырэнне даступна для выкарыстання. Невялікія паведамленні могуць траціць значны час на падрыхтоўку і навакольны код, у той час як вялікія нагрузкі таксама залежаць ад памяці і паралелізму.
Як праверыць падтрымку і актыўнасць
Для арыгінальнага пашырэння SHA праверце CPUID.07H.00H:EBX біт 29 пасля праверкі падтрымкі ліста. Правярайце алгарытм і дакладнае сямейства інструкцый, запытаных бібліятэкай, а не проста агульную пазнаку sha, паказаную ўтылітай.
Выкарыстоўвайце падтрымліваемую крыптаграфічную рэалізацыю, якая бярэ на сябе выбар функцый, апрацоўку збояў і выкананне поўнага алгарытму. Апаратнае паскарэнне дае прымітывы; кіраванне ключамі, аўтэнтыфікацыя, правілы выкарыстання nonce і выбар пратакола застаюцца задачамі праграмнага забеспячэння.
Чаго гэта функцыя не гарантуе
Існаванне інструкцыі не робіць SHA-1 прыдатным для новага пратакола бяспекі. Апаратнае паскарэнне не змяняе ўстойлівасць алгарытму да калізій і не выпраўляе небяспечны дызайн пратакола. Больш познія пашырэнні SHA512 маюць асобнае пералічэнне.
Сумяшчальнасць і прадукцыйнасць на практыцы
Поле функцыі не з'яўляецца сертыфікацыяй прадукту або доказам таго, што канкрэтная праграма бяспечная. Прадукцыйнасць залежыць ад памераў паведамленняў, рэжыму, пакетавання і астатняй часткі пратакола. Праверце фактычнага пастаўшчыка рашэння і рэгулярна абнаўляйце яго патчы бяспекі.
Практычны чэк-ліст для праверкі
- Зафіксуйце дакладную мадэль працэсара або платформы, а таксама задзейнічаныя версіі праграмы, АС і асяроддзя выканання. Захавайце дакладную фармулёўку памылкі або патрабавання.
- Звярніцеся да дакументацыі вытворцы для гэтай канкрэтнай мадэлі, затым праверце фактычныя магчымасці і ўключаны стан у асяроддзі, дзе выконваецца праграма.
- Супастаўце кожнае патрабаванне выбранага выканальнага файла або бэкэнда. Аналагічнай назвы функцыі, псеўданіма або агульнай назвы тэхналогіі недастаткова.
- Пацвердзіце, што праграма выбрала патрэбную рэалізацыю. Выкарыстоўвайце яе задакументаваныя сродкі дыягностыкі і падтрымліваемы запасны варыянт, калі патрабаванні не выконваюцца.
- Уносьце па адным падтрымліваемым змяненні за раз і паўтарайце тую ж нагрузку. Захоўвайце зыходную канфігурацыю і магчымасць адкату.
Калі функцыя пазначана, але праграмнае забеспячэнне не можа яе выкарыстоўваць
Пачніце з канкрэтнага кампанента, які выклікае збой. Апаратная база даных апісвае зафіксаваныя магчымасці; аперацыйная сістэма або гіпервізар могуць прадастаўляць іншае фактычнае асяроддзе. Памылка недапушчальнай інструкцыі (illegal instruction) таксама патрабуе даследавання канкрэтнай інструкцыі, якая выклікала збой, і зборкі бінарнага файла, паколькі пашкоджанне даных або іншая непадтрымліваемая інструкцыя могуць выклікаць аналагічны сімптом.
Усталюйце версію праграмы, драйвера або асяроддзя выканання, якая падтрымліваецца для дадзенай платформы, і пры неабходнасці выкарыстоўвайце задакументаваную вытворцам базавую або запасную зборку. Абнаўленне ПЗ не можа стварыць інструкцыю, якой няма ў працэсары. Змяненні ў мікрапраграме (firmware) і палітыках бяспекі павінны адпавядаць працэдурам вытворцы сістэмы і плану аднаўлення, а не агульным рэцэптам аптымізацыі.
Крыніцы і межы прымянення гэтага тлумачэння
Intel 64 and IA-32 Architectures Software Developer's Manual · Стандарт бяспечнага хэшавання NIST, FIPS 180-4
Гэтыя даведнікі вызначаюць архітэктурныя паводзіны і патрабаванні да праграмнага забеспячэння. Яны не пацвярджаюць незалежна кожнае значэнне функцыі на звязанай старонцы мадэлі абсталявання. Для праверкі падтрымкі мадэллю выкарыстоўвайце даныя вытворцы на адпаведнай старонцы і правярайце фактычную канфігурацыю сістэмы. Гэты артыкул не змяшчае вынікаў тэсціравання (benchmark), сертыфікацыі або даты незалежнага агляду.
Крыніцы і праверка
Рэдакцыйная прыналежнасць: Feex. Дата незалежнай праверкі не зафіксавана. Як мы даследуем.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Тамы 1 і 2 апісваюць названыя сямействы інструкцый і CPUID; Том 3 апісвае стан, старонкавую арганізацыю памяці, VMX і элементы кіравання абаронай. Архітэктурная дакументацыя не пацвярджае падтрымку канкрэтнай мадэлі.
- Стандарт бяспечнага хэшавання NIST, FIPS 180-4 · Вызначае названыя алгарытмы SHA. Вызначэнні алгарытмаў не азначаюць, што арыгінальнае пашырэнне x86 SHA паскарае кожны з іх.
Ці быў гэты артыкул карысным?
Дастаткова адказаць "так" або "не". Выберыце прычыну, калі хочаце, або дадайце кароткую нататку.
Дзякуй. Гэта дапамагае нам паляпшаць гэтую старонку.