Một số khuyến nghị về việc sử dụng an toàn giao thức trao đổi khóa ECDH

1. Giới thiệu

Trao đổi khóa là một quá trình đặc biệt quan trọng trong mật mã. Ngày nay, khi chúng ta yêu cầu mức độ an toàn cao hơn thì xu hướng sử dụng các giao thức trao đổi khóa dựa trên ECC trở nên phổ biến hơn bởi vì kích thước khóa của các hệ mật ECC nhỏ hơn nhiều so với các hệ mật mã khóa công khai khác. NIST đã chuẩn hóa mật mã ECC cho các giao thức thiết lập khóa trong SP 800-56A. Chuẩn SEC1 khuyến nghị sử dụng hai giao thức trao đổi khóa dựa trên ECC, đó là ECDH (Elliptic curve Diffie-Hellman (giao thức trao đổi khóa Diffie - Hellman dựa trên Elliptic)) và ECMQV (Elliptic curve Menezes-Qu-Vanstone (giao thức trao đổi khóa Menezes-Qu-Vanstone dựa trên Elliptic)). Ngoài ra, tài liệu [2] cũng chỉ ra nhiều chuẩn khác khuyến nghị dùng hai giao thức trao đổi khóa này như ANS X9.63, IEEE 1363.3, IETF S/MIME, ISO 15946 hay NIST SP 800-56A., ECMQV có khả năng cung cấp các mục đích an toàn giống với ECDH ngoại trừ mục đích xác thực khóa ẩn đơn phương. Bài viết này sẽ tập trung vào giao thức ECDH với bố cục các phần tiếp theo như sau: Phần 2 giới thiệu giao thức ECDH, phần 3 trình bày một số vấn đề an toàn của ECDH, phần 4 giới thiệu một số khuyến nghị của các chuẩn về việc sử dụng an toàn ECDH và phần 5 là kết luận.

2. Giao thức ECDH

ECDH  là một giao thức trao đổi khóa dựa trên ECC. Nó được thiết kế để cung cấp một loạt các mục đích an toàn tùy theo từng ứng dụng như xác thực khóa ẩn đơn phương; xác thực khóa ẩn lẫn nhau; đảm bảo an toàn khóa đã biết và an toàn chuyển tiếp, phụ thuộc vào các yếu tố như liệu các khóa công khai có được trao đổi theo cách xác thực không và liệu cặp khóa là tạm thời hay là tĩnh (không thay đổi theo thời gian). Giao thức này cũng chính là một biến thể của giao thức Diffie-Hellman (DH).

Để có thể sử dụng được giao thức ECDH, hai bên A và B trước hết cần thiết lập sơ đồ. Ở giai đoạn này, A và B sẽ thống nhất sử dụng nguyên mẫu ECDH tiêu chuẩn hoặc phần phụ đại số (được giải thích ở bước 3 của giai đoạn trao đổi khóa), có thể thiết lập hàm dẫn xuất khóa nếu muốn. Đồng thời A và B cũng cần thiết lập các tham số miền của ECC ở mức an toàn mong muốn T = (p, a, b, G, n, h) hoặc (m, f(x), a, b, G, n, h) để xác định một nhóm ECC E trên trường hữu hạn F_p là y² = x³ + ax + b mod p, hoặc trên F₂m là y² + xy = x³ +ax² +b tương ứng, trong đó p là một số nguyên tố lớn, G là điểm cơ sở trên E(F_p) hoặc E(F₂m), n là bậc của G, và số nguyên h là phần phụ đại số (co factor) sao cho h = # E(F_pz)/n hoặc h = #E(F₂m)/n (với # E(F_p) hoặc # E(F_pm) là số các điểm thuộc # E(F_p) hoặc E(F₂m) tương ứng, trường hợp lý tưởng là h = 1 ).

Tiếp theo A và B sẽ thực hiện trao đổi khóa bằng cách tính toán khóa bí mật dùng chung dựa trên ECDLP (bài toán logarit rời rạc dựa trên ECC - Elliptic Curve Discrete Logarithm Problem) như sau:

1. Mỗi bên chọn ngẫu nhiên một số nguyên d trong đoạn [2,n -1] (đây chính là khóa riêng) và tính khóa công khai được biểu diễn bởi một điểm Q, trong đó Q = d.G. Giả sử cặp khóa của A và B lần lượt là (d_A, Q_A) và (d_B, Q_B).
2. A và B gửi khóa công khai của mình cho bên còn lại.
3. Nếu hai bên thống nhất sử dụng nguyên mẫu ECDH tiêu chuẩn thì A tính toán điểm  và B tính . Ngược lại, nếu dùng nguyên mẫu ECDH phần phụ đại số thì A tính toán điểm (x_k, y_k) = d_A . Q_B và B tính (x_k, y_k) = d_B . Q_A. Ngược lại, nếu dùng nguyên mẫu ECDH phần phụ đại số thì A tính toán điểm x_k, y_k) = h. d_A . Q_B và tính (x_k, y_k) = h. d_B . Q_A..
4. Khóa bí mật dùng chung là x_k (hoành độ của điểm trên ECC). Hầu hết các giao thức được tiêu chuẩn hóa dựa trên ECDH lấy một khóa đối xứng từ x_k sử dụng hàm lấy khóa dựa trên hàm băm nào đó.

Dễ thấy hai bên tính khóa bí mật dùng chung là bằng nhau. A và B chỉ công bố thông tin duy nhất là khóa công khai vì vậy không ai ngoại trừ bản thân họ có thể xác định được khóa riêng của mình trừ khi giải được ECDLP.

3. Một số vấn đề về an toàn của ECDH

Phần này bài viết sẽ trình bày về tính khó của bài toán Diffie - Hellman dựa trên ECC (ECDHP - Elliptic Curve Diffie - Hellman Problem) và các tấn công lên ECDH.

3.1 Tính khó của ECDHP

ECDH là giao thức trao đổi khóa dựa trên ECC. Theo tài liệu tính an toàn của tất cả các giao thức mật mã dựa trên ECC phụ thuộc vào ECDLP vì vậy tính khó của ECDHP liên quan mật thiết với tính khó của ECDHP. Cho tới nay chưa có thuật toán hàm mũ con tổng quát nào được biết đến có thể giải được ECDLP.

Bảng 1 minh họa độ khó của ECDLP, nó chứa các ước tính theo MIPS (triệu chỉ lệnh trên giây - Million Instructions Per Second) năm của khả năng tính toán cần thiết để giải ECDLP trên một đường cong chung trong phần mềm sử dụng phương pháp Pollard-ρ cải tiến. Trong bảng 1 này, Odlyzko đã ước tính rằng 0,1% khả năng tính toán thực hiện trong 1 năm sẽ lên tới  MIPS vào năm 2004 và  hoặc  MIPS vào năm 2014.

Bảng 1. Khả năng tính toán cần để giải ECDLP [2]

Ngoài ra, chúng ta cũng có thể tìm hiểu thêm thông tin về tính khó của ECDLP trong các tài liệu khác như ANS X9.63, Blake, Seroussi và Smart, Hankerson, Menezes và Vanstone…

3.2 Một số tấn công lên ECDH

Một số phương pháp tấn công đã biết trên ECDH như: Tấn công vào ECDLP hoặc ECDHP; Tấn công vào quá trình tạo khóa; Tấn công Man-in-the-middle; Tấn công vào hàm dẫn xuất khóa; Các tấn công dựa trên việc sử dụng các tham số miền không hợp lệ; Tấn công dựa trên việc sử dụng khóa công khai không hợp lệ. Ngoài ra cũng có thể xảy ra các tấn công phi mã hóa trên ECDH ví dụ “các tấn công thực thi” như tấn công dựa trên lỗi (fault-based attacks), tấn công phân tích công suất (power-analysis attacks) và tấn công phân tích thời gian (timing-analysis attacks).

Như vậy để đảm bảo an toàn khi sử dụng ECDH thì cần phải chống được các tấn công nói trên. Điều này liên quan đến sự lựa chọn của những người thực thi về một số tùy chọn để đáp ứng yêu cầu an toàn của hệ thống. Những lựa chọn này thường sẽ được thực hiện dựa trên các tiêu chí như tính hiệu quả, khả năng tương tác và các vấn đề an toàn như đã nêu ở trên. Đặc biệt, một số lựa chọn đối với các tham số miền của ECC, lựa chọn hàm dẫn xuất khóa, … Phần 4 dưới đây sẽ trình bày một số khuyến nghị của các tiêu chuẩn quốc tế và trong nước hướng dẫn người thực thi thực hiện những lựa chọn này.

4. Một số khuyến nghị về việc sử dụng an toàn ECDH

4.1 Khuyến nghị về tham số miền dùng trong ECDH

Để sử dụng ECDH an toàn thì các tham số miền của ECC cần được lựa chọn cẩn thận để có thể chống lại được tất cả các tấn công đã biết vào ECDLP. Đầu tiên cần xác định mức an toàn mong muốn dựa trên một số tiêu chí như giá trị của thông tin mà giao thức sẽ được dùng để bảo vệ, thời gian sử dụng tham số, … Bảng 2 dưới đây cung cấp thông tin liên quan tới việc xác định mức an toàn ứng với kích thước khóa của ECC cũng như thời gian đảm bảo an toàn theo SEC1[2]. Tuy nhiên tùy thuộc mỗi quốc gia, khi triển khai vận dụng có thể có những thay đổi theo hướng nâng cao độ an toàn, ví dụ ở Việt Nam, trong Thông tư số 23 của Bộ Quốc Phòng khuyến nghị kích thước khóa của ECC với độ dài 256 sẽ được sử dụng cho tới năm 2027 để đảm bảo an toàn  cho giao thức ECDH thay vì năm 2040 như khuyến nghị của SEC1.

Bảng 2. Ước lượng thời gian đảm bảo an toàn của khóa ECC ứng với mức an toàn

Khi đã lựa chọn được mức an toàn mong muốn thì tiến hành lựa chọn các tham số miền (p, a, b, G, n, h). Có một số cách để sinh ra các tham số miền này mức độ an toàn mong muốn. Các cách này bao gồm:

- Chọn trường hữu hạn thích hợp rồi chọn ngẫu nhiên một đường cong trên trường. Tiếp theo, sử dụng một số thuật toán như Schoof, Schoof-Elkies-Atkin (SEA) hoặc Satoh hoặc các thuật toán cải tiến để đếm số điểm trên đường cong n = # E(F_p) và kiểm tra xem liệu số điểm có gần như nguyên tố không. Lặp lại cho tới khi tìm được các tham số thích hợp.

- Chọn một trường thích hợp rồi chọn một bậc thích hợp của đường cong và tạo ra đường cong trên trường với số điểm sử dụng các kĩ thuật dựa trên “phép nhân phức tạp”.

- Chọn một trường hữu hạn thích hợp sau đó chọn một ECC trên trường từ một họ đặc biệt của các đường cong mà bậc của nó dễ tính (chẳng hạn như họ các đường cong Koblitz). Tính số điểm của đường cong và kiểm tra xem giá trị này có gần như nguyên tố không. Lặp lại cho đến khi tìm được các tham số thích hợp.

Phương pháp đầu tiên (chọn ngẫu nhiên các tham số miền ECC) là cách lựa chọn thận trọng nhất bởi vì nó cung cấp một đảm bảo về mặt xác suất chống lại các tấn công có mục đích chuyên dụng trong tương lai tương tự như tấn công Menezes-Okamoto-Vanstone và Semaev-Smart-Satoh-Araki. Tuy nhiên, các thực thi hiện có của thuật toán Schoof kém hiệu quả hơn so với việc thực thi các phương pháp lựa chọn tham số khác (nhưng trong trường hợp thuật toán của Satoh và các cải tiến của nó, sự khác biệt có thể không đáng kể). Phương pháp thứ hai (chọn tham số miền ECC bằng cách sử dụng phép nhân phức tạp) tạo ra tham số hiệu quả hơn so với phương pháp đầu tiên. Phương pháp thứ ba (chọn các tham số miền ECC từ một họ đặc biệt) cũng tạo ra các tham số hiệu quả hơn so với phương pháp đầu tiên, và có thêm sức hút hơn so với một số họ đường cong đặc biệt (chẳng hạn như họ các đường cong Koblitz) cho phép tăng tốc các tính toán như phép nhân vô hướng. Tuy nhiên, dù phương pháp thứ hai và thứ ba có nhiều ưu điểm nhưng cần rất thận trọng khi sử dụng vì chúng tạo ra các tham số có thể dễ bị ảnh hưởng bởi các tấn công có mục đích chuyên dụng trong tương lai.

Chọn ngẫu nhiên các tham số miền của ECC có thể áp dụng sự sàng lọc tốt hơn thông qua ý tưởng chọn ngẫu nhiên các tham số miền của ECC có thể kiểm chứng được. Điều này liên quan đến việc lựa chọn ngẫu nhiên các tham số từ một mầm theo cách mà các tham số không thể được xác định trước. Cách này tốt hơn vì mầm cung cấp bằng chứng mà bất kỳ ai đều có thể xác minh được rằng không có “cửa sập” được đặt trong các tham số. Tham khảo phương pháp lựa chọn các tham số ngẫu nhiên có thể kiểm chứng trong mục 3.1.3 của tài liệu và trong ANS X9.62. Tài liệu cung cấp danh sách các tham số miền của ECC được tính toán trước ở nhiều mức an toàn khác nhau thường được yêu cầu (xem bảng 4). Việc sử dụng các tham số được tính toán trước này được khuyến khích mạnh mẽ để thúc đẩy khả năng tương tác. Khi các tham số miền của ECC đã được tạo, bởi chính người dùng hoặc bởi một bên thứ ba thì mong muốn nhận được một số đảm bảo rằng các tham số là hợp lệ như các tham số sở hữu các thuộc tính số học được mong đợi từ các tham số an toàn. Sự xác thực tham số giảm thiểu việc vô tình tạo ra các tham số không an toàn do lỗi mã hóa và chống lại những nỗ lực cố ý lừa người dùng sử dụng các tham số không an toàn.

Chuẩn ANS X9.62 chỉ định tham số miền của ECC n >2¹⁶⁰ để đáp ứng yêu cầu an toàn của ngành công nghiệp ngân hàng. Chuẩn IPSec chỉ định cho tham số F2_m trên m thỏa mãn  là hợp số.

Có thể tìm thêm thông tin bổ sung về việc tạo và xác thực các tham số miền của ECC trong ANS X9.62, ANS X9.63 và IEEE 1363. Ngoài ra có thể tham khảo chi tiết các tham số miền của các ECC ngẫu nhiên mà NIST đã khuyến nghị sử dụng trong chuẩn FIPS 186 cũng như trong.

4.2 Khuyến nghị về sử dụng ECDH trong một số giao thức mạng an toàn

Nhiều chuẩn đã đưa ra khuyến nghị sử dụng ECDH trong các giao thức mạng an toàn. Trước hết bài viết đề cập tới SSL - tiền thân của TLS (Transport Layer Security). SSL là tiêu chuẩn công nghệ bảo mật được phát triển để thiết lập liên kết được mã hóa giữa máy chủ web và trình duyệt. Liên kết phải đảm bảo quyền riêng tư và tính toàn vẹn của tất cả dữ liệu được truyền giữa máy chủ web và trình duyệt. Trước khi máy khách và máy chủ có thể bắt đầu trao đổi thông tin được bảo vệ bởi SSL, họ phải trao đổi hoặc đồng ý với nhau một khóa mã hóa và một hệ mật để sử dụng khi mã hóa dữ liệu. Cả khóa và hệ mật này đều phải có tính bảo mật cao. ECDH là một trong những phương pháp an toàn được sử dụng để trao đổi khóa.

SSL bao gồm hai lớp, lớp dưới quản lý mật mã đối xứng vì vậy thông tin liên lạc là riêng tư và đáng tin cậy, và lớp trên được gọi là giao thức bắt tay. DH được sử dụng ở lớp trên này nhưng trong nhiều trường hợp thì ECDH là thích hợp hơn, đặc biệt RFCs 4492 đã chỉ định một bộ mật mã trên ECC cho TLS trong đó đều sử dụng ECDH.

RFCs 8422 và RFCs 8446 đều chỉ định sử dụng ECDH với khóa tạm thời (ECDHE) cho TLS 1.2, TLS 1.3 và phiên bản trước đó trong giai đoạn bắt tay của TLS. Bảng 3 mô tả các thuật toán trao đổi khóa dựa trên ECC mới cho TLS mà chuẩn này xác định. Chúng được dùng để tính toán bí mật tiền chủ TLS (TLS premaster secret) và chỉ khác nhau về mặt cơ chế.

Bảng 3. Các thuật toán trao đổi khóa đối với TLS

Hai chuẩn này chỉ ra ECDH sử dụng các ECC như curve25519 và curve448 ứng với bí mật tiền chủ có độ dài chính xác lần lượt là 32 byte và 56 byte. Các tham số miền ứng với curve25519 cụ thể là:

p=2²⁵⁵  -19, a = 486662, b=1, h=8,

n=2²⁵⁵+ 0x14def9de a2f79cd6 5812631a 5cf5d3ed

và bậc của đường cong này là h.n.

Các tham số miền ứng với curve448 [13] cụ thể là:

p=2⁴⁴⁸ - 2²²⁴  -1, a = 156326, b = 1, h = 4,

n=2²⁵⁵+ 0 x14def9de a2f79cd6 5812631a 5cf5d3ed

và bậc của đường cong này là h.n.

Một giao thức mạng an toàn khác cũng được khuyến nghị dùng ECDH, đó là SSH. Đây là một giao thức mạng mật mã để cho phép đăng nhập từ xa và các dịch vụ mạng khác hoạt động an toàn trên một mạng không an toàn. Nó thường được sử dụng và rất phổ biến để đăng nhập an toàn trên mạng. Trong giai đoạn trao đổi khoá bí mật dùng chung của SSH thường dùng DH và tất nhiên chúng ta cũng có thể sử dụng ECDH. Cụ thể theo SEC 1, RFC 5656 đã chỉ định giao thức trao đổi khóa ECDH với khóa tạm thời. Ngoài ra FIPS 140-2 với các ECC do NIST đề nghị ứng với khóa có độ dài là P-256 bit, P-384 bit và P-521 bit cũng chỉ định ECDH.

4.3 Khuyến nghị về sử dụng ECDH trong các ứng dụng khác

RFCs 8418 đưa ra các quy ước đối với việc sử dụng ECDH với curve25519 và curve448 trong cú pháp tin nhắn mật mã (CMS - Cryptographic Message Syntax). Khóa ECDH dùng trong chuẩn này bao gồm cả khóa tĩnh và tạm thời. Thỏa thuận khóa được hỗ trợ trong 3 kiểu nội dung CMS, đó là dữ liệu được che giấu (enveloped-data), dữ liệu được xác thực (authenticated-data) và dữ liệu được che giấu và xác thực (authenticated-enveloped-data).

RFCs 6637 chỉ định sử dụng ECDH trong OpenPGP với hạn chế phần phụ đại số phải là 1 và 3 ECC do NIST đề nghị giống như FIPS 140-2.

RFCs 8551 chỉ định phải sử dụng ECDH có khóa tĩnh hoặc tạm thời cho S/MIME 4.0 với ECC có độ dài khóa là P-256 bit và curve25519.

NIST SP 800-56A Revision 3 chỉ định sử dụng ECDH cùng với 12 ECC trên trường F₂m, trên trường  và họ ECC Koblitz đặc biệt trên trường như ở bảng 4 dưới đây.

Bảng 4. Các ECC được chấp nhận cho trao đổi khóa ECC

ISO/IEC 13157-2:2016 phần 2 và 3 chỉ định sử dụng ECDH với ECC có độ dài khóa là P-256 bit

Từ những năm 2000 IEEE 1363 và bản gần đây là IEEE 1363.3 xuất bản vào năm 2013 đã khuyến nghị dùng ECDH với tên là ECKAS-DH1 để trao đổi khóa cùng với một số giao thức trao đổi khóa khác.

Ở Việt Nam, Thông tư số 39/2017/TT-BTTTT ngày 15/12/2017 của Bộ trưởng Bộ Thông tin và Truyền thông đã công bố Danh mục tiêu chuẩn kỹ thuật về ứng dụng công nghệ thông tin trong cơ quan nhà nước quy định Khuyến nghị áp dụng tiêu chuẩn ECDHE -  Elliptic Curve Diffie Hellman Ephemeral và được xếp vào nhóm Tiêu chuẩn về an toàn thông tin. Gần đây nhất, thông tư số 23/2022/TT-BQP, QCVN 12:2022/BQP [4] đã đưa ra Quy chuẩn kỹ thuật quốc gia về đặc tính kỹ thuật mật mã sử dụng trong các sản phẩm dân sự thuộc nhóm sản phẩm bảo mật luồng IP sử dụng công nghệ IPSEC và TLS, trong đó ECDH là một trong các thuật toán mật mã phi đối xứng được yêu cầu sử dụng cùng với các thuật toán khác như RSA, DSA, ECDSA, DH GOST R 34.10-2001 và GOST 34.10-2012. Tài liệu này cũng quy định kích thước tham số theo bit của thuật toán ECDH là  bit và được sử dụng đến năm 2027. Đối với quy định về an toàn sử dụng trong giao thức TLS không cho phép trao đổi khóa dựa trên thuật toán DH sử dụng khóa tĩnh.

5. Kết luận

ECDH là giao thức trao đổi khóa ẩn danh an toàn đang được khuyến cáo sử dụng bởi rất nhiều tiêu chuẩn quốc tế cũng như trong nước đặc biệt là trong nhiều giao thức an toàn mạng như TLS, SSH, … và các ứng dụng trong ngành tài chính, ngân hàng. Có một số tấn công có thể thực hiện đối với ECDH tuy nhiên bài toán ECDHP được xem là khó như bài toán ECDLP, bằng việc lựa chọn các tham số miền phù hợp cho các ECC thì ECDH có thể đáp ứng an toàn cho các ứng dụng. Không những vậy, cho tới nay chưa có nghiên cứu nào cho thấy có các cuộc tấn công hiệu quả lên ECDH vì vậy ECDH vẫn là giao thức trao đổi khóa đảm bảo an toàn và có xu thế được sử dụng nhiều trong thực tiễn. Các tham số miền cũng có tác động tới độ an toàn của ECDH, chúng thường được lựa chọn theo các khuyến nghị của các tiêu chuẩn nổi tiếng trên thế giới như FIPS 186-4, ANS X9.63, NIST SP 800-56A, SEC2…  tùy theo mức độ an toàn mong muốn trong từng ứng dụng.

Tài liệu tham khảo

1. Rakel Haakegaard and Joanna Lang, “The Elliptic Curve Diffie-Hellman (ECDH)”, 2015

2. Daniel R. L. Brown, “SEC 1: Elliptic Curve Cryptography”, Certicom Corp, 2009.

3. Daniel R. L. Brown, “SEC 2: Recommended Elliptic Curve Domain Parameters”, Certicom Corp, 2010.

4. QCVN 12: 2022/BQP, Quy chuẩn kỹ thuật quốc gia về đặc tính kỹ thuật mật mã sử dụng trong các sản phẩm mật mã dân sự thuộc nhóm sản phẩm bảo mật luồng IP sử dụng công nghệ IPSEC và TLS, BQP, 2022

5. Thông tư Ban hành danh mục tiêu chuẩn kỹ thuật về ứng dụng công nghệ thông tin trong cơ quan nhà nước, Bộ Thông tin và Truyền thông, 2017

6. Joppe W. Bos và cộng sự, “Elliptic Curve Cryptography in Practice”, International Association for Cryptologic Research, 2013, https://eprint.iacr.org/2013/734.pdf

7. Dr. Lily Chen, Dr. Dustin Moody, “Elliptic Curve Cryptography”, NIST, 2023 https://csrc.nist.gov/Projects/elliptic-curve-cryptography

8. Y. Nir, S. Josefsson, “Elliptic Curve Cryptography (ECC) Cipher Suites

for Transport Layer Security (TLS) Versions 1.2 and Earlier”, RFC 8422, 2018.

9. E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, 2018.

10. R. Housley, “Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)”, RFC 8418, 2018.

11. A. Jivsov, “Elliptic Curve Cryptography (ECC) in OpenPGP”, RFC 6637, 2012.

12. Elaine Barker, Lily Chen, Allen Roginsky, Apostol Vassilev, Richard Davis, “Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography”, NIST SP 800-56A Revision 3, 2018.

13. Lily Chen, Dustin Moody, Andrew Regenscheid, Karen Randal “Recommendations for Discrete 4 Logarithm-Based Cryptography: Elliptic Curve Domain Parameters”, Draft NIST SP 800-186, 2019

14. “OpenSSH Client Cryptographic Module”, FIPS 140-2 Non-Proprietary Security Policy, 2021.

15. J. Schaad, B. Ramsdell, S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification”, RFC 8551, 2019.

16. D. Stebila, J. Green “Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer”, RFC 5656, 2009.