Dalawang profile ang sinusukat sa parehong gateway, isa na may encryption at isa na wala, at ang naka-encrypt ay hindi mas mabagal. Kung minsan ito ay mas mabilis, na kadalasan ay nagdudulot ng mahabang pagtatalo kung ang pagsubok ay isinagawa nang tama. Ang resulta ay makatwiran, dahil ang gastos ng isang packet ay hindi ang bilang ng mga salitang kriptograpiko sa konfigurasyon. Ito ay ang hanay ng mga operasyong ginagawa ng implementasyon, sa hardware na mayroon ito, ayon sa layout ng buffer na pinili nito.

Ang sintomas: ang mabagal ay hindi ang naka-encrypt na profile

Ipagpalagay na ang isang makasaysayang pagsubok ay naghahambing ng AEAD cipher sa isang mode na „walang encryption“ na nagkukuwenta pa rin ng hiwalay na authentication code bawat packet. Ang ikalawang profile ay nagtatago ng nilalaman ng payload ngunit nagpapanatili ng hash bawat packet, at sa isang processor na walang acceleration para sa hash na iyon ay maaaring mas mahal ito kaysa sa pinagsamang konstruksiyon na dapat nitong talunin.

Sinasabi ng label sa konfigurasyon na „encryption“, at ang label ang tanging tinitingnan ng karamihan ng paghahambing. Iba ang sinasabi ng landas ng packet: ang isang profile ay gumagawa ng pinagsamang operasyon kung saan may mga instruksiyon ang CPU, at ang isa ay gumagawa ng hiwalay na wala ito. Ang pagbasa lamang ng file ng konfigurasyon ay hindi kailanman magbubunyag ng pagkakaibang iyon, dahil ang dalawang entry ay mukhang isang linya. Tanging ang napagkasunduang mode at ang landas ng code sa likod nito ang nagpapaliwanag ng resulta.

Iyon ang buong paliwanag, at hindi ito nangangailangan ng anumang pahayag kung aling primitive ang pandaigdigang mas mabilis. Parehong maaaring mabilis, parehong maaaring mabagal, at ang pagkakasunod-sunod ay nakasalalay sa makina at code.

Bilangin ang mga operasyon, hindi ang mga label

Ang konstruksiyong AEAD, gaya ng inilalarawan ng RFC 5116, ay nagbibigay sa implementasyon ng isang interface na nagbabalik ng ciphertext at tag nang magkasama. Ang AES-GCM ay isang halimbawa: encryption sa counter mode na pinagsama sa isang Galois authenticator. Hindi ginagawang libre ng interface ang integridad; ginagawa nitong mahusay na natukoy ang kombinasyon, at iyon ang nagpapahintulot sa implementasyon na i-optimize ang pares bilang isang yunit.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

Ito ay mga sketch ng pagpoproseso, hindi payo sa konfigurasyon. Ang una ay walang pagiging lihim ngunit gumagastos pa rin ng CPU sa authentication, at iyon mismo ang dahilan kung bakit ang „patayin ang encryption“ ay hindi kasingkahulugan ng „patayin ang gawaing kriptograpiko“.

Ang pangalawa ay maaaring mas mura dahil ang mga processor ay nagbibigay ng mga instruksiyon para sa dalawang hati: mga round ng AES at ang multiplication na walang carry na ginagamit ng larangan ng Galois. Ang mga library ay nagpoproseso rin ng mga independiyenteng buffer nang sabay, na nagpapanatili sa mga instruksiyong iyon na abala sa halip na maghintay sa memorya.

Ano ang aktuwal na pinapagana ng napagkasunduang mode

Sa Community OpenVPN, ang AEAD data cipher ay nangangahulugang ang opsiyon auth ay hindi na nag-aambag ng sarili nitong hiwalay na HMAC ng data channel. Inilalarawan ng reference ng opsiyon sa encryption ang saklaw na iyon, at iyon ang dahilan kung bakit ang dalawang konfigurasyon na magkamukha sa isang text file ay maaaring magkaiba sa trabaho bawat packet.

Basahin ang napagkasunduang mode sa halip na ang listahan ng hangarin. Ang listahan ng pinapayagang cipher at ang pangalan ng TLS suite ay hindi nagsasabi kung aling mga operasyon ang tumatakbo sa payload, at ang lumang linyang cipher ay maaaring hindi naglalarawan ng pinili ng kasalukuyang koneksiyon.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

Ang unang utos ay naglilista ng mga cipher na sinusuportahan ng binary, na isang listahan ng kakayahan at hindi ang napagkasunduang resulta. Ipinapakita ng pangalawa kung ano ang aktuwal na hinihiling ng server. Ang log ng koneksiyon ang lugar upang kumpirmahin ang huling pagpili, dahil ang client ay maaaring mahulog sa isang bagay na pinapayagan ng server ngunit walang sinuman ang naglayon.

Sukatin ang workload na aktuwal na pinapatakbo mo

Ang isang mikrobenchmark na kriptograpiko ay sumusukat ng isang primitive sa sarili nitong mga kondisyon. Ang isang paglilipat ng VPN ay kumokopya rin ng mga buffer, nag-iiskedyul ng mga thread o interrupt, nagsusuri ng polisiya at tumatawid sa network. Ang mga bahaging iyon ay kadalasang nangingibabaw, kaya ang mas mabilis na primitive ay hindi laging nagbubunga ng mas mabilis na tunnel.

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

Ang dalawang utos na iyon ay nagbibigay sa iyo ng magaspang na lokal na paghahambing ng mga primitive sa makinang nasa harap mo, at tapat sila na sila ay mga mikrobenchmark. Wala silang sinasabi tungkol sa throughput ng iyong tunnel, at hindi sila dapat kailanman sipiin bilang ganoon.

Pagkatapos ay sukatin ang workload na mahalaga, na pinapanatiling pare-pareho ang lahat ng iba pa: parehong endpoint, parehong laki ng packet, parehong transport, parehong patakaran sa compression. Kung binago rin ng pagbabago ng profile ang transport o ang lokasyon ng pagpoproseso, inilalarawan ng resulta ang bundle na iyon at hindi ang kriptograpiya.

Panatilihin din ang layunin sa paningin. Ang isang landas ng data na may sobrang kakayahang kriptograpiko ay maaari pa ring maging limitado ng latency dahil naghihintay ang aplikasyon ng mga paglalakbay pabalik-balik, at ang mga pakinabang sa maramihang kapasidad ay hindi nag-aayos ng isang madaldal na protocol. Sukatin ang suportado at inaprubahan ng polisiyang konfigurasyon sa kabuuan, at ituring ang „mas kaunting kahon ay dapat mas mabilis“ bilang ang hipotesis na ito nga. Ang kapaki-pakinabang na tanong ay hindi kung ang encryption ay may gastos, kundi kung lumilitaw ang gastos sa pagsukat na talagang pinapahalagahan mo.

Kaugnay na mga artikulo