Đối với dự án tôi đang thực hiện, tôi cần triển khai ECDSA trên đường cong NIST P-384 (AKA secp384r1). Đối với giá trị của nó, việc lựa chọn đường cong nằm ngoài tầm kiểm soát của tôi trong trường hợp cụ thể này.
Mặc dù tôi đã có một triển khai đang hoạt động và đây (cho đến nay) chỉ là một dự án thú cưng có mức cổ phần thấp, nhưng tôi đã tự hỏi làm thế nào để tôi có thể giải quyết vấn đề này một cách hiệu quả nhất. có hiệu lực cách, đặc biệt là đối với phần ký kết.
Danh sách mong muốn thô:
- Tôi muốn thực hiện một nỗ lực nghiêm túc trong việc bảo vệ chống rò rỉ kênh phụ và thời gian.
- Vì tôi chỉ quan tâm đến đường cong P-384 và ECDSA, nên tôi muốn một cơ sở mã có dấu chân tương đối nhỏ (cũng bởi vì tôi sẽ cần cung cấp các ràng buộc cho mã không phải C). Tuy nhiên, các tối ưu hóa dành riêng cho P384 chắc chắn được hoan nghênh.
- Tôi muốn tùy chọn sử dụng xác định kiểu RFC 6979 $k$ các giá trị (hoặc một số lược đồ dẫn xuất nonce xác định khác).
- Lược đồ tôi đang triển khai cũng yêu cầu hỗ trợ nén điểm.
Tôi có thể tự xử lý 3 và 4 nếu cơ sở mã cho phép sửa đổi.
Sau khi tìm kiếm xung quanh, đây là những gì tôi tìm thấy:
- OpenSSL (và các nhánh của nó như LibreSSL/BoringSSL/...): sự lựa chọn rõ ràng, nhưng cồng kềnh và tôi cũng không phải là người hâm mộ các quy ước gọi baroque của OpenSSL
- Android bao gồm triển khai P-256 tối giản dễ thương. Tôi không chắc nó an toàn đến mức nào cụ thể một là, nhưng đó là một ví dụ điển hình về loại thứ tôi đang tìm kiếm (thay thế P-256 bằng P-384).
- BearSSL của Thomas Pornin có triển khai P-384 di động nhưng không đổi trong thời gian (đến mức có thể) và trông đủ đơn giản để loại bỏ chức năng mà tôi không cần. Nó dường như không sử dụng bất kỳ tối ưu hóa cụ thể nào cho đường cong, nhưng đã sử dụng xác định $k$ giá trị ra khỏi hộp.
Rõ ràng là tôi muốn tránh phải thực hiện triển khai của riêng mình. Ngay bây giờ, tôi rất muốn đi theo lộ trình "bỏ BearSSL", nhưng tôi muốn hỏi liệu có bất cứ điều gì bổ sung thêm hay liệu có bất kỳ mối lo ngại nào mà tôi đã bỏ sót hay không. Cảm ơn!
