DKIM გასაღებები და როტაცია: selector-ები, ზომები, გამოქვეყნება

DKIM გასაღები გასაღებების წყვილია: პირადი ნახევარი საფოსტო სერვერზე რჩება და ყველა გამავალ წერილს ხელს აწერს, საჯარო ნახევარი DNS-შია განთავსებული სახელის ქვეშ, რომელსაც selector ჰქვია, და მიმღებები მას ხელმოწერის შესამოწმებლად იღებენ. გამოიყენე 2048-ბიტიანი RSA გასაღები - 1024 არის მინიმუმი, რომელსაც სტანდარტი ჯერ კიდევ უშვებს, და ის საკმარისად აღარ ითვლება, 4096 კი DNS-ში პრობლემებს ქმნის პრაქტიკული სარგებლის გარეშე. დაამატე Ed25519 გასაღებიც მის გვერდით, თუ შენს სერვერს ორივეთი ხელმოწერა შეუძლია. როტაცია ასე კეთდება: აქვეყნებ ახალ selector-ს, ხელმოწერას მასზე გადართავ და ძველ საჯარო გასაღებს DNS-ში სულ მცირე ერთი კვირით ტოვებ წაშლამდე, რადგან ძველი გასაღებით ხელმოწერილ წერილებს მისი გამოყენების შეწყვეტის შემდეგაც ამოწმებენ. ეს არის მთელი პროცედურა; პოსტის დანარჩენი ნაწილი ის დეტალებია, რომლებიც მას შეუფერხებლად ატარებს.

ფონი - რატომ არსებობს DKIM და როგორ უკავშირდება SPF-სა და DMARC-ს - არის პოსტში SPF, DKIM და DMARC ახსნილი. ეს პოსტი ვარაუდობს, რომ იცი, რისთვის არის DKIM, და გინდა გასაღებები სწორად მართო.

რას შეიცავს ხელმოწერა#

როცა შენი სერვერი წერილს ხელს აწერს, ის ამატებს ასეთ header-ს:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;  s=s2026a; t=1791446400; h=from:to:subject:date:message-id:mime-version;  bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;  b=Ys9Bd7pLq2T...

მიმღები იღებს s=-სა და d=-ს, აწყობს სახელს s2026a._domainkey.example.com, იქიდან TXT ჩანაწერს იღებს და b=-ს საჯარო გასაღებით ამოწმებს. თუ შემოწმება გავიდა და body-ს ჰეში კვლავ bh=-ს ემთხვევა, ხელმოწერა გადის.

ხელმომწერის ორი პარამეტრი ღირს შემოწმებად. გამოიყენე relaxed/relaxed კანონიკალიზაცია: simple ფუჭდება უწყინარ ცვლილებებზე ჰარებში, რომლებსაც გზაში მყოფი სერვერები აკეთებენ. და დარწმუნდი, რომ From: არის h=-ში, რასაც სტანდარტი მოითხოვს; კარგი ხელმომწერები მას ორჯერაც წერენ ("oversigning"), რომ თავდამსხმელმა ხელმოწერის გაფუჭების გარეშე მეორე From: header ვერ დაამატოს.

მოერიდე l= ტეგს, თუ შენი სერვერი მას გთავაზობს. ის ხელმოწერილ body-ს ბაიტების რაოდენობით ზღუდავს, რომ მოგვიანებით დამატებულმა ფუტერებმა ხელმოწერა არ გააფუჭოს - რაც ასევე ნიშნავს, რომ ნებისმიერს შეუძლია შენს ხელმოწერილ წერილს შინაარსი მიაწეროს და ის მაინც გაივლის შემოწმებას.

Selector-ები და რატომ გაქვს რამდენიმე#

Selector უბრალოდ ლეიბლია, რომელიც ერთ დომენს საშუალებას აძლევს, ერთდროულად ბევრი გასაღები გამოაქვეყნოს. თითოეულ გამგზავნ სისტემას თავისი აქვს:

s2026a._domainkey       IN TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."s2026e._domainkey       IN TXT    "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="pm._domainkey           IN TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."selector1._domainkey    IN CNAME  selector1-example-com._domainkey.provider.example.

პირველი ორი შენი საფოსტო სერვერის RSA და Ed25519 გასაღებებია. მესამე ტრანზაქციულ სერვისს ეკუთვნის. მეოთხე არის CNAME პროვაიდერის ზონაში - ზოგი პროვაიდერი (ცნობილი მაგალითია Microsoft 365) გთხოვს, მათ selector-ებზე CNAME გააკეთო, რომ გასაღებები თავის მხარეს დაატრიალონ ისე, რომ DNS-ში ხელის ხლება არ მოგთხოვონ.

Selector-ები არაფერი ღირს და ერთმანეთს არ ეჯახება, ამიტომ ისე დაარქვი, რომ ერთი წლის შემდეგაც გაიგო, რა არის. გავრცელებული სქემები შეიცავს თარიღს (s2026a, 202610), სისტემას (mail, app) ან ორივეს. Stalwart-ის ბოლო ვერსიები selector-ებს შაბლონიდან აგენერირებს, რომლის ნაგულისხმევი მნიშვნელობა v1-rsa-20261008-ს ჰგავს - ვერსია, ალგორითმი, თარიღი - და ეს კარგი სქემაა გადასაღებად, თუ გასაღებებს თვითონ აგენერირებ.

გასაღებების ტიპები და ზომები#

RFC 8301 ამბობს, რომ ხელმომწერებმა აუცილებლად უნდა გამოიყენონ სულ მცირე 1024-ბიტიანი RSA გასაღებები და სასურველია - სულ მცირე 2048-ბიტიანი; შემმოწმებლებმა 1024 ბიტზე მოკლე გასაღებები ვალიდურად არ უნდა ჩათვალონ. 1024-ბიტიანი RSA კარგად დაფინანსებული თავდამსხმელების მიღწევადობის ფარგლებშია, და ზოგი დიდი მიმღები მას სუსტად თვლის. 2048 გონივრული მინიმუმია.

4096-ბიტიანი გასაღებები პრაქტიკაში მეტ სარგებელს არ იძლევა. მარტო საჯარო გასაღები დაახლოებით 700 სიმბოლოა base64-ში, TXT პასუხმა შეიძლება ტრადიციულ 512-ბაიტიან UDP DNS ლიმიტს გადააჭარბოს, და ზოგი DNS პროვაიდერის რედაქტორი მის შენახვას ვერ ახერხებს. Resolver-ებს შეუძლიათ TCP-ზე გადავიდნენ, მაგრამ შენ ჩავარდნის ახალ გზებს ამატებ ისეთი უსაფრთხოებისთვის, რომელიც ჯერ არავის სჭირდება.

Ed25519 (RFC 8463) თანამედროვე არჩევანია: მოკლე გასაღებები, მოკლე ხელმოწერები, სისწრაფე. პრობლემა შემოწმების მხარდაჭერაა - ყველა დიდი მიმღები Ed25519 ხელმოწერებს არ ამოწმებს, და ხელმოწერა, რომელიც მიმღებს არ ესმის, იგნორირდება და არა ჩაჭრილად ითვლება. ამიტომაა პრაქტიკა ორმაგი ხელმოწერა: თითოეულ წერილს ხელს აწერ როგორც RSA, ისე Ed25519 გასაღებით. მიმღებებს, რომლებსაც Ed25519 ესმით, შეუძლიათ ის გამოიყენონ; დანარჩენები RSA-ს იყენებენ. Stalwart ამას ახალი დომენებისთვის ნაგულისხმევად აკეთებს.

გასაღებების გამოქვეყნება DNS-ში#

ჩანაწერის ფორმატი:

v=DKIM1; k=rsa; p=<base64 public key>

v=DKIM1 არასავალდებულოა, მაგრამ მიღებულია, და თუ არის, პირველი უნდა იყოს. k=-ის ნაგულისხმევი მნიშვნელობაა rsa; Ed25519 გასაღებებს k=ed25519 სჭირდება. p= გასაღებს ინახავს. არასავალდებულო ტეგები: t=y დომენს DKIM-ის ტესტირების რეჟიმში მონიშნავს (მიმღებებმა ჩავარდნებს ხელმოუწერელი ფოსტისგან განსხვავებულად არ უნდა მოეპყრონ - წაშალე, როცა ყველაფერი იმუშავებს), ხოლო t=s მოითხოვს, რომ d= იდენტობას ზუსტად ემთხვეოდეს და არა ქვედომენს.

2048-ბიტიანი RSA გასაღები დაახლოებით 400 სიმბოლოა base64-ში, ხოლო ერთ DNS TXT სტრიქონში მაქსიმუმ 255 ეტევა. ამიტომ ჩანაწერი ინახება რამდენიმე სტრიქონად, რომლებსაც მიმღებები აერთებენ:

s2026a._domainkey IN TXT ( "v=DKIM1; k=rsa; "    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3...first part..."    "...second part...IDAQAB" )

ვებ DNS რედაქტორების უმეტესობა გრძელ მნიშვნელობებს ავტომატურად ყოფს. ზოგი მოითხოვს, რომ ბრჭყალებში ჩასმული სტრიქონები თვითონ ჩასვა; რამდენიმე კი ჩუმად წყვეტს. გამოქვეყნების შემდეგ წამოიღე და შეადარე:

$ dig +short TXT s2026a._domainkey.example.com"v=DKIM1; k=rsa; " "p=MIIBIjANBgkq...first..." "...second...IDAQAB"

პასუხში ბრჭყალებში ჩასმული რამდენიმე სტრიქონი ნორმალურია. გასაღები, რომელიც იმაზე მოკლეა, რაც სერვერმა მოგცა, ან base64-ის შიგნით ჰარებით ან ბრჭყალებით - არა.

თუ გასაღებებს ხელით აგენერირებ და არა საფოსტო სერვერს აკეთებინებ, ამას openssl გააკეთებს:

# RSA 2048: private key, then the public key as DKIM wants it$ openssl genrsa -out s2026a.private 2048$ openssl rsa -in s2026a.private -pubout -outform der | openssl base64 -A# Ed25519: DKIM wants the raw 32-byte public key, not the DER wrapper$ openssl genpkey -algorithm ed25519 -out s2026e.private$ openssl pkey -in s2026e.private -pubout -outform der | tail -c 32 | openssl base64 -A

გასაღებების როტაცია ფოსტის გაფუჭების გარეშე#

საერთოდ რატომ უნდა დაატრიალო: გაჟონილი პირადი გასაღები ნებისმიერს აძლევს საშუალებას, შენი დომენის სახელით მოაწეროს ხელი, სანამ არ შეამჩნევ; ძველი გასაღებები, როგორც წესი, სუსტია; და თანამშრომლები, რომლებსაც ოდესღაც სერვერზე წვდომა ჰქონდათ, მიდიან. ხშირად ციტირებული ინდუსტრიული რეკომენდაცია (M3AAWG-ის) არის როტაცია სულ მცირე ყოველ ექვს თვეში. ბევრი ორგანიზაცია ამას ყოველწლიურად აკეთებს; წელიწადში ერთხელ საიმედოდ შესრულებული როტაცია ქაღალდზე არსებულ კვარტალურს ჯობია.

უსაფრთხო თანმიმდევრობა:

1. დააგენერირე ახალი გასაღები ახალი selector-ის ქვეშ. არასოდეს გამოიყენო selector-ის სახელი ხელახლა სხვა გასაღებისთვის - მიმღებები და resolver-ები ძველ ჩანაწერს მისი TTL-ის განმავლობაში ქეშავენ, და ახალი გასაღებით გაკეთებული ხელმოწერები ქეშირებულ ძველთან შემოწმებისას ჩავარდება.
2. გამოაქვეყნე ახალი საჯარო გასაღები და შეამოწმე გარედან dig-ით. დაელოდე სულ მცირე ჩანაწერის TTL-ს, რომ ყველა resolver-მა დაინახოს.
3. ხელმოწერა ახალ გასაღებზე გადართე. ამ მომენტიდან ახალი ფოსტა ატარებს s=-ს ახალი selector-ით.
4. ძველი საჯარო გასაღები გამოქვეყნებული დატოვე სულ მცირე შვიდი დღით. ძველი გასაღებით ხელმოწერილი ფოსტა შეიძლება რიგებში იდოს, ხელახლა იცდებოდეს, გადაიგზავნოს, ან მიმღებმა გვიან შეამოწმოს თავიდან სკანირებისას.
5. გააუქმე ძველი გასაღები. ან წაშალე ჩანაწერი, ან გამოაქვეყნე ის ცარიელი გასაღებით (v=DKIM1; p=), რასაც RFC 6376 გაუქმებულად განსაზღვრავს. ცარიელი p= ოდნავ მეტ ინფორმაციას აძლევს მას, ვინც მოგვიანებით გამართვას დაიწყებს.
6. გაანადგურე ძველი პირადი გასაღები, როცა დარწმუნებული იქნები, რომ მისით აღარაფერი აწერს ხელს.

ხშირი შეცდომაა მე-3 და მე-5 ნაბიჯების ერთად გაკეთება - ხელმოწერის გადართვა და ძველი ჩანაწერის წაშლა ერთდროულად - რაც ყველა გზაში მყოფ წერილს აჭრის. მეორე შეცდომაა მე-3 ნაბიჯის გაკეთება მანამ, სანამ მე-2 დალაგებას მოასწრებს, რაც ფოსტის პირველ საათს აჭრის.

ავტომატური როტაცია Stalwart-ში

Stalwart-ის ბოლო ვერსიებს ამ სასიცოცხლო ციკლის თვითონ მართვა შეუძლიათ: თითოეულ დომენს აქვს DKIM-ის მართვის პარამეტრი, რომელიც ან ხელითაა, ან ავტომატური. ავტომატური რეჟიმი გასაღებებს გრაფიკით ატრიალებს (ნაგულისხმევად 90 დღე), ჩანაცვლებული გასაღების DNS ჩანაწერს გადართვის შემდეგ 7 დღით გამოქვეყნებულს ტოვებს და გასაღების მასალას ამის შემდეგ 30 დღეში შლის. მას ავტომატური DNS მართვა სჭირდება - API წვდომა შენს DNS პროვაიდერზე - რადგან ჩანაწერების გამოქვეყნება და მოგვიანებით წაშლა თვითონ უწევს. ამის გარეშე როტაცია ხელით რჩება: დააგენერირე ახალი ხელმოწერა ვებ ადმინკაში, გამოაქვეყნე მისი ჩანაწერი, გადართე და ძველი მოგვიანებით წაშალე ზემოთ მოცემული თანმიმდევრობით. აქ ვერსიის დეტალებს მნიშვნელობა აქვს, ამიტომ შეამოწმე დოკუმენტაცია იმ რელიზისთვის, რომელსაც უშვებ.

საგანგებო როტაცია გაჟონვის შემდეგ#

ზემოთ მოცემული გრაფიკი რუტინული როტაციისთვისაა. თუ პირადი გასაღები შეიძლება გაჟონილიყო - სერვერის კომპრომეტირება, საჯარო bucket-ში დატოვებული backup, ყოფილი ადმინისტრატორი, რომელმაც ასლი შეინახა - თანმიმდევრობა იცვლება, რადგან ახლა საფრთხე ძველი გასაღებია.

1. დააგენერირე და გამოაქვეყნე ახალი გასაღები ახალი selector-ის ქვეშ, ზუსტად ისე, როგორც ადრე, და ხელმოწერა მასზე გადართე, როგორც კი ჩანაწერი საჯარო resolver-იდან გადაწყდება. სრულ TTL-ს ნუ დაელოდები; წუთებს მეტი მნიშვნელობა აქვს, ვიდრე რამდენიმე ჩავარდნილ ხელმოწერას.
2. ძველი გასაღები დაუყოვნებლივ გააუქმე ცარიელი p=-ით. გზაში მყოფი ზოგიერთი ლეგიტიმური წერილი DKIM-ზე ჩავარდება. ეს ფასია და ის მცირეა: SPF მათთვის ჩვეულებრივ მაინც გადის, ხოლო DMARC-ს მხოლოდ ერთი aligned გავლა სჭირდება.
3. შეამოწმე DMARC-ის aggregate ანგარიშები მომდევნო კვირებში. ძველი selector-ით ხელმოწერილი წერილები შენთვის უცნობი IP მისამართებიდან იმის მტკიცებულებაა, რომ გასაღები გამოიყენეს.
4. გაარკვიე, როგორ გაჟონა, სანამ შემდეგი გასაღებიც იმავე გზით წავა. როტაცია არ გიშველის, თუ ახალი პირადი გასაღები იმავე დაუცველ ადგილას დევს.

ყველამ, ვინც დომენს მართავს, უნდა იცოდეს, სად ინახება მისი DKIM პირადი გასაღებები და ვის შეუძლია მათი წაკითხვა. თუ პასუხია "backup არქივში, რომლის ჩამოტვირთვაც რამდენიმე ადამიანს შეუძლია", ამ არქივს ისეთივე სიფრთხილით მოეპყარი, როგორც თავად გასაღებს.

სხვა გამგზავნების ხელში არსებული გასაღებები#

შენი საფოსტო სერვერი იშვიათად არის ერთადერთი სისტემა, რომელიც შენი დომენის სახელით ხელს აწერს. საინფორმაციო ბიულეტენის პლატფორმა, helpdesk, ინვოისების ხელსაწყო და ტრანზაქციული ელფოსტის სერვისი თითოეული ხელს აწერს გასაღებით, რომელიც მათ აქვთ, იმ selector-ის ქვეშ, რომელიც შენ მათთვის გამოაქვეყნე. რამდენიმე რამ მათ შესახებ:

• მათ როტაციას თვითონ ვერ გააკეთებ, თუ პროვაიდერი ამას არ გთავაზობს. ბევრი პროვაიდერი თავის მხარეს ატრიალებს ზემოთ აღწერილი CNAME მოწყობით, რაც კარგი მიზეზია, CNAME მეთოდი აირჩიო, როცა მას გთავაზობენ.
• წაშალე selector-ები იმ სერვისებისთვის, რომლებსაც აღარ იყენებ. გასაღებს, რომლის პირადი ნახევარი ეკუთვნის მომწოდებელს, რომელსაც აღარ უხდი, კვლავ შეუძლია შენი დომენისთვის ვალიდური ფოსტის ხელმოწერა. კონტრაქტის დასრულებისას ჩანაწერი წაშალე.
• აწარმოე ინვენტარი. მოკლე სია - selector, სისტემა, მფლობელი და გამოქვეყნების თარიღი - dig-ით არქეოლოგიის მთელ შუადღეს დაგიზოგავს. მის აწყობაში DMARC ანგარიშები გეხმარება: მათში ყოველი გავლილი DKIM ხელმოწერა თავის selector-ს ასახელებს.
• თვალი ადევნე პროვაიდერებს, რომლებიც საკუთარი დომენით აწერენ ხელს. თუ სერვისი ხელს აწერს d=provider.example-ით და არა შენი დომენით, მისი ხელმოწერა გადის, მაგრამ არ არის aligned, და ამ ფოსტისთვის DMARC მხოლოდ SPF-ზე იქნება დამოკიდებული. სერვისების უმეტესობას შენი დომენით ხელმოწერა შეუძლია, როგორც კი მათ ჩანაწერს გამოაქვეყნებ.

როცა DKIM ვარდება#

მიღებულ წერილზე Authentication-Results header ჩავარდნის მიზეზს ასახელებს:

• `dkim=fail (body hash did not verify)` - body ხელმოწერის შემდეგ შეიცვალა. საფოსტო სიის ფუტერი, უსაფრთხოების gateway, რომელიც ბმულებს გადაწერს, ანტივირუსი, რომელიც შეტყობინებას ამატებს, ან simple body კანონიკალიზაცია, რომელიც ჰარების ცვლილებას წააწყდა.
• `dkim=fail (signature verification failed)` - header-ები შეიცვალა, ან გამოქვეყნებული გასაღები პირად გასაღებს არ ემთხვევა. როტაციის შემდეგ ეს ჩვეულებრივ ნიშნავს, რომ არასწორი ჩანაწერი გამოქვეყნდა.
• `dkim=neutral` ან `permerror (no key)` - მიმღებმა selector-ზე გასაღები ვერ იპოვა. შეამოწმე, სახელში დომენი ორჯერ ხომ არ წერია, და რომ s=-ში მყოფი selector ემთხვევა იმას, რაც გამოაქვეყნე.
• `dkim=permerror (key syntax)` - ჩანაწერი დამახინჯებულია: აკლია p=, base64-ის შიგნით ზედმეტი ბრჭყალებია, ან გასაღები შეკვეცილია.
• `dkim=pass`, მაგრამ `dmarc=fail` - ხელმოწერა გავიდა დომენისთვის, რომელიც From:-თან aligned არ არის, ხშირად პროვაიდერის საკუთარი დომენისთვის. alignment-ისთვის იხილე DMARC ანგარიშები და პოლიტიკის დანერგვა.

საფოსტო სიების მიერ ხელმოწერების გაფუჭება მოსალოდნელია და მისი გასწორება შენი საქმე არ არის; ARC (Authenticated Received Chain) header-ები იმისთვის არსებობს, რომ სიებმა თავდაპირველი შედეგი დაადასტურონ.

DKIM RE:NODE-ის Mail Server-ზე#

Mail Server ხაზზე Stalwart მუშაობს, და მისი ვებ ადმინკა ყოველი დამატებული დომენისთვის DKIM გასაღებებს აგენერირებს და გამოსაქვეყნებელ ჩანაწერებს გაჩვენებს. მათ აქვეყნებ იქ, სადაც შენი DNS-ია განთავსებული - ჩვენს მხარეს ზონის რედაქტორი არ არის - MX-თან, SPF-თან და DMARC-თან ერთად. გასაღებები სერვერის მონაცემთა საცავში ინახება, ამიტომ შენი გეგმის backup სლოტები (ერთიდან ოთხამდე, ტარიფის მიხედვით) მათ საფოსტო ყუთებთან ერთად ფარავს. თუ ვებ ადმინკაში დაყენებული relay-ით აგზავნი, Stalwart მაინც ჯერ შენი გასაღებებით აწერს ხელს. დომენის დამატება და ჩანაწერების სიის წაკითხვა აღწერილია პოსტში Stalwart საფოსტო სერვერის დაყენება.

FAQ#

DKIM გასაღების რა ზომა გამოვიყენო?

RSA 2048. მას უნივერსალური მხარდაჭერა აქვს და DNS-ში ჩვეულებრივი სტრიქონებად დაყოფით ეტევა. დაამატე Ed25519 მის გვერდით, თუ შენს სერვერს ორმაგი ხელმოწერა შეუძლია. ახალი გასაღებებისთვის მოერიდე 1024-ს და მოერიდე 4096-ს, რომელიც DNS-ში პრობლემებს ქმნის პრაქტიკული სარგებლის გარეშე.

შეიძლება ერთზე მეტი DKIM ჩანაწერი მქონდეს?

კი, თითო selector-ზე ერთი, რამდენიც გინდა. თითოეულ გამგზავნ სისტემას თავისი უნდა ჰქონდეს. რაც არ შეიძლება, ეს არის ორი განსხვავებული გასაღები ერთი და იმავე selector-ის სახელზე.

რამდენ ხანს დავტოვო ძველი გასაღები როტაციის შემდეგ?

სულ მცირე შვიდი დღე მას შემდეგ, რაც მისით ხელმოწერას შეწყვეტ, უფრო დიდხანს, თუ აგზავნი ფოსტას, რომელიც შეიძლება გარკვეული დროის განმავლობაში ხელახლა იცდებოდეს ან გადაიგზავნოს. შემდეგ გააუქმე ის ცარიელი p=-ით ან წაშალე.

უნდა დავატრიალო გასაღებები, თუ არაფერი გაჟონილა?

ვერ გაიგებ, თუ რამე გაჟონა. ყოველ ექვს-თორმეტ თვეში როტაცია ზღუდავს, რამდენ ხანს რჩება ჩუმად მოპარული გასაღები გამოსადეგი, და პროცედურას ნაცნობს ტოვებს იმ დღისთვის, როცა ის სასწრაფოდ დაგჭირდება.

რატომ არ აჩვენებს ჩემი Ed25519 ხელმოწერა შედეგს Gmail-ში?

იმიტომ, რომ ყველა მიმღები Ed25519-ს ჯერ არ ამოწმებს. უცნობი ხელმოწერა იგნორირდება და არა ჩაჭრილად ითვლება. ამიტომაც აწერ ხელს RSA-თიც - შედეგს RSA ხელმოწერა ატარებს.