Перайсці да змесціва

Пашырэнні інструкцый SHA

Архітэктурны даведнікFeex

Таксама называецца 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 маюць асобнае пералічэнне.

Сумяшчальнасць і прадукцыйнасць на практыцы

Поле функцыі не з'яўляецца сертыфікацыяй прадукту або доказам таго, што канкрэтная праграма бяспечная. Прадукцыйнасць залежыць ад памераў паведамленняў, рэжыму, пакетавання і астатняй часткі пратакола. Праверце фактычнага пастаўшчыка рашэння і рэгулярна абнаўляйце яго патчы бяспекі.

Практычны чэк-ліст для праверкі

  1. Зафіксуйце дакладную мадэль працэсара або платформы, а таксама задзейнічаныя версіі праграмы, АС і асяроддзя выканання. Захавайце дакладную фармулёўку памылкі або патрабавання.
  2. Звярніцеся да дакументацыі вытворцы для гэтай канкрэтнай мадэлі, затым праверце фактычныя магчымасці і ўключаны стан у асяроддзі, дзе выконваецца праграма.
  3. Супастаўце кожнае патрабаванне выбранага выканальнага файла або бэкэнда. Аналагічнай назвы функцыі, псеўданіма або агульнай назвы тэхналогіі недастаткова.
  4. Пацвердзіце, што праграма выбрала патрэбную рэалізацыю. Выкарыстоўвайце яе задакументаваныя сродкі дыягностыкі і падтрымліваемы запасны варыянт, калі патрабаванні не выконваюцца.
  5. Уносьце па адным падтрымліваемым змяненні за раз і паўтарайце тую ж нагрузку. Захоўвайце зыходную канфігурацыю і магчымасць адкату.

Калі функцыя пазначана, але праграмнае забеспячэнне не можа яе выкарыстоўваць

Пачніце з канкрэтнага кампанента, які выклікае збой. Апаратная база даных апісвае зафіксаваныя магчымасці; аперацыйная сістэма або гіпервізар могуць прадастаўляць іншае фактычнае асяроддзе. Памылка недапушчальнай інструкцыі (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 паскарае кожны з іх.

Ці быў гэты артыкул карысным?

Дастаткова адказаць "так" або "не". Выберыце прычыну, калі хочаце, або дадайце кароткую нататку.

Ці быў гэты артыкул карысным?