AES-GCM თუ ChaCha20-Poly1305: VPN მონაცემთა შიფრის არჩევა
AES-GCM აშკარა არჩევანია ტექნიკური აჩქარების მქონე სერვერებზე, ხოლო ChaCha20-Poly1305 კარგად მუშაობს მის გარეშეც. შესაძლოა თქვენმა პროტოკოლმა თქვენ ნაცვლად გადაწყვიტოს.
ორივე სახელი AEAD კონსტრუქციაა, ორივე სტანდარტიზებულია და თანამედროვე x86 სერვერზე ნებისმიერი მათგანი გიგაბიტიან არხს შეავსებს შესამჩნევი ძალისხმევის გარეშე. არჩევანი თვითნებური რომ აღარ იყოს, საჭიროა იმ სერვერიდან გასვლა: იაფ როუტერებს, ძველ ტელეფონებსა და ვირტუალურ მოწყობილობებს ხშირად არ აქვთ AES აჩქარება და იქ სხვაობა დიდია. ამიტომ შედარება არ არის რომელი შიფრი უფრო სწრაფია, არამედ რომელი შიფრი მუშაობს კარგად ამ საბოლოო წერტილების სიმრავლეზე და საერთოდ გვთავაზობს თუ არა პროტოკოლი არჩევანს.
იგივე სამუშაო, სხვადასხვა ბირთვი
ორივე კონსტრუქცია ერთ გავლაში იძლევა კონფიდენციალურობასა და მთლიანობას და ავთენტიფიცირებს დაკავშირებულ მონაცემებს, ამიტომ VPN პროტოკოლები მათ მონაცემთა არხისთვის იყენებენ. განსხვავება შიგნითაა: AES-GCM არის AES ბლოკური შიფრი მრიცხველის რეჟიმში GF(2^128) ზე მრავალწევრიანი ავთენტიფიკატორით, ხოლო ChaCha20-Poly1305 არის 256 ბიტიანი გასაღების ნაკადური შიფრი ცალკე ერთჯერადი ავთენტიფიკატორით.
ოპერაციულად მნიშვნელოვანი საერთოა: ორივე კატასტროფულად ფუჭდება nonce-ის განმეორებით გამოყენებისას, ორივეს სჭირდება nonce სივრცის მართვა თითოეული გასაღებისთვის და არც ერთი არ ასწორებს პარტნიორს, რომელიც არასწორს ავთენტიფიცირებს. პროფილი, რომელიც ამბობს AES-256-GCM, არ არის უფრო უსაფრთხო, ვიდრე ის, რომელიც ამბობს CHACHA20-POLY1305; ორივე ძლიერია, როცა იმპლემენტაცია სწორია.
სად იმარჯვებს AES-GCM
AES-ს აქვს გამოყოფილი ინსტრუქციები უმეტეს თანამედროვე პროცესორზე: AES-NI x86-ზე, კრიპტო გაფართოებები ARMv8-ზე და ეკვივალენტები ბოლო POWER და RISC-V დიზაინებზე. როცა ისინი არსებობს, GCM რამდენიმე ბლოკს პარალელურად ამუშავებს ციკლის კლასზე და პროგრამული იმპლემენტაცია უმნიშვნელო ხდება. ეს ჩვეულებრივი შემთხვევაა სერვერებისთვის, სამაგიდო კომპიუტერებისა და ამჟამინდელი ტელეფონებისთვის და ამიტომაა, რომ მონაცემთა ცენტრში AES-ის გამოყენების რჩევა გონივრული ნაგულისხმევია.
პრობლემა მეორე რიგის შემთხვევაა. გამოყოფილი ინსტრუქციების გარეშე AES პროგრამულად ნელია და ცხრილებით მართული პროგრამული იმპლემენტაციები სწორედ ისინი არიან, რომელთაც cache-ის დროის პრობლემების გრძელი ისტორია აქვთ. VPN კონცენტრატორი ვირტუალურ მანქანაში, რომლის ჰოსტი სტუმარს AES დროშებს არ აჩვენებს, ზუსტად ეს შემთხვევაა და ადვილად გამოტოვებადია, რადგან ჰოსტის პროცესორს ეს ფუნქცია აქვს.
შეამოწმეთ, რასაც პროცესი რეალურად ხედავს და არა რასაც პროცესორი მხარს უჭერს: grep -o aes /proc/cpuinfo | head -1 Linux-ზე, ან ეკვივალენტური ფუნქციის დროშა ჰიპერვიზორის პროცესორის მოდელში.
სად იმარჯვებს ChaCha20-Poly1305
ChaCha20 სწრაფია გადატანად პროგრამულ უზრუნველყოფაში, რადგან იყენებს მხოლოდ შეკრებას, ბრუნვასა და XOR-ს და მისი იმპლემენტაციები დიზაინით თავს არიდებენ საიდუმლოზე დამოკიდებულ ცხრილურ ძიებას. AES აჩქარების გარეშე მოწყობილობაზე ეს მატერიალური უპირატესობაა და ამიტომ აირჩია WireGuard-მა ის: WireGuard პროტოკოლის აღწერა ChaCha20-Poly1305-ს ასახელებს მის მონაცემთა შიფრად ალტერნატივის გარეშე.
ეს ერთი არჩევანი რაღაც სასარგებლოს ამბობს: ტექნიკაზე, სადაც AES აჩქარებულია, WireGuard გარკვეულ გამტარუნარიანობას თმობს AES-GCM-თან შედარებით და მისმა ავტორებმა ეს მიიღეს ტელეფონებზე, სახლის როუტერებსა და კონტეინერ ჰოსტებზე წინასწარმეტყველებადი ქცევის სანაცვლოდ. თუ თქვენი ფლოტი ძირითადად პატარა ARM ყუთებია, ეს გაცვლა თქვენს სასარგებლოდაა.
საპირისპირო შემთხვევა დატვირთული x86 კონცენტრატორია, სადაც AES-GCM AES-NI-ით უფრო სწრაფი და უკეთ მხარდაჭერილი გზაა და სადაც ChaCha20 ყოველ გიგაბიტზე გაზომვად პროცესორს ხარჯავს. არც ერთი კონსტრუქცია სისუსტე არ არის; კითხვა ისაა, რომელს ასრულებს თქვენი ტექნიკა იაფად.
რისი არჩევის საშუალებას გაძლევთ პროტოკოლი
| Protocol | What you get |
|---|---|
| WireGuard | ChaCha20-Poly1305 only; no negotiation |
| OpenVPN 2.5 and later | Data channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 |
| IPsec / IKEv2 | AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it |
| OpenVPN control channel | TLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites |
ყურადღება მიაქციეთ OpenVPN-ის გაყოფას: საკონტროლო არხი და მონაცემთა არხი ცალ-ცალკე მოლაპარაკდება, ამიტომ TLS-ისთვის ნანახი კრებული არაფერს ამბობს იმ შიფრზე, რომელიც თქვენს დატვირთვას იცავს. სესიის შეჯამება ორივეს აცნობებს და ორიდან მხოლოდ ერთის წაკითხვა გაუგებრობის ჩვეულებრივი წყაროა.
OpenVPN-ში მონაცემთა არხის შიფრი მოდის data-ciphers სიიდან ორივე მხარეს. თუ სერვერის სია და კლიენტის სია არ იკვეთება, კავშირი ან უკან იხევს იმაზე, რასაც data-ciphers-fallback უშვებს, ან სრულად ფუჭდება და ეს მარცხი ჩვეულებრივ არასწორ ფენას მიეწერება. დააყენეთ იგივე სია ორივე მხარეს, შემდეგ დაადასტურეთ მოლაპარაკებული შედეგი ჟურნალში იმის ნაცვლად, რომ ჩათვალოთ სიის რიგის დაცვა.
გადაწყვიტეთ განლაგების სამი ფაქტის მიხედვით
პირველი, აქვთ საბოლოო წერტილებს AES აჩქარება? თუ ყველა პარტნიორს აქვს, AES-GCM იაფი არჩევანია და ნაგულისხმევი უმეტეს შენახულ კონფიგურაციაში. თუ მნიშვნელოვანი წილი პატარა როუტერები ან ძველი ტელეფონებია, ChaCha20-Poly1305 ხელს უშლის ფლოტის კუდს გახდეს ტევადობის ზღვარი.
მეორე, გვთავაზობს პროტოკოლი საერთოდ არჩევანს? WireGuard-თან გადაწყვეტილება თქვენ ნაცვლად მიღებულია და სასარგებლო სამუშაოა დაადასტუროთ, რომ მის ირგვლივ ინსტრუმენტები ჩუმად სხვას არ ცვლის. OpenVPN-სა და IPsec-თან პასუხი კონფიგურაციის ხაზია და ჩასაწერი მოლაპარაკებული შედეგი.
მესამე, შეუძლიათ ორივე მხარეს შეთანხმება? შიფრი, რომელსაც ერთი პარტნიორი არ ახორციელებს, არ არის წარმადობის გადაწყვეტილება, ეს შეწყვეტაა. ამიტომ პარტნიორთა სია ნებისმიერ საზომზე მნიშვნელოვანია: შერეულ ფლოტს შესაძლებლობათა კვეთა სჭირდება და არა ყველაზე სწრაფი მანქანის უპირატესობა.
თუ ზომავთ, მოწყობილობა, საბოლოო წერტილი და დატვირთვა იდენტური დატოვეთ და ერთი რამ შეცვალეთ. ტესტი, რომელიც ორ სერვერს სხვადასხვა რეგიონში ადარებს, მარშრუტს ზომავს და არა შიფრს, ხოლო ლეპტოპის საზომი არაფერს ამბობს კონტეინერ ჰოსტზე, რომლის პროცესორის დროშები დაფარულია. შეადარეთ და შემდეგ ჩაწერეთ, რომელი შიფრი იქნა რეალურად მოლაპარაკებული: ეს ჩანაწერი საზომზე უფრო ღირებულია.