Tóm tắt
Tài liệu này mô tả một sơ đồ ví xác định phân cấp hoạt động với mật mã lưới.
Động lực
Ví xác định phân cấp (HD-Wallets) đã trở thành tiêu chuẩn thực tế trong blockchain. Khi ngành blockchain thảo luận về tương lai hậu lượng tử, chúng tôi muốn áp dụng kỹ thuật này cho các key trong bối cảnh mật mã lưới, vì trải nghiệm người dùng sao lưu một seed phrase duy nhất để tạo ra các key không liên quan a-priori là rất được ưa thích hơn so với việc người dùng phải sao lưu lại ví mỗi khi thực hiện một hành động.
Chúng tôi tập trung vào phương thức chữ ký Dilithium vì đây là chữ ký hậu lượng tử NIST đầu tiên được hoàn thiện và có khả năng trở thành tiêu chuẩn ngành.
Thách thức khi điều chỉnh mật mã lưới cho một cài đặt HD là hai mặt. Thứ nhất là đầu ra của HMAC-SHA512 không thể được sử dụng ngay lập tức cho một key riêng của lưới. Đối với Falcon và Dilithium, chúng ta cần các đa thức tạo nên một "cơ sở tốt" (vector nhỏ) cho lưới, và các thuật toán tạo key sử dụng lấy mẫu từ chối, điều này không phù hợp với sơ đồ ví HD mà không có sự điều chỉnh.
Thách thức thứ hai là trong BIP32, các key không được gia cố được derivate thông qua phép cộng các điểm đường cong elliptic (key công khai) và không có phép toán tương đương nào cho các lưới: tập hợp các key công khai lưới không đóng dưới phép cộng hoặc nhân.
Chúng tôi giải quyết thách thức đầu tiên trong QIP này và không cố gắng hỗ trợ các key không được gia cố. Theo hiểu biết của chúng tôi, việc liệu thách thức thứ hai có thể được vượt qua trong bối cảnh mật mã lưới hay không vẫn là một câu hỏi nghiên cứu mở. Các key không được gia cố được sử dụng cho các ví chỉ xem hoặc kiểm toán và không thiết yếu cho mục đích chính của HD-Wallets, vì vậy chúng tôi không coi đây là một nhược điểm quan trọng.
Đặc tả
Ý tưởng cơ bản là sử dụng đầu ra entropy từ HMAC tại mỗi lần lặp làm RNG để lấy mẫu đa thức. Trong BIP32, một nửa đầu ra của HMAC được sử dụng làm key riêng, trực tiếp như trong trường hợp "được gia cố", hoặc được cộng vào key riêng trước đó, trong trường hợp "không được gia cố". Điều này hoạt động do cấu trúc của các thuật toán mật mã đường cong elliptic, nơi key riêng có thể được xem như một số nguyên được nhân với điểm sinh trong nhóm đường cong elliptic.
Trong cả Falcon và Dilithium, các thuật toán tạo key tiêu thụ <= 64 byte entropy trong quá trình derivate key. Chúng ta có thể đơn giản là đưa toàn bộ đầu ra HMAC vào quá trình tạo key, thay vì sử dụng một nửa làm key riêng, nhưng để tối đa hóa khả năng tương tác với các ví BIP44, chúng tôi chỉ sử dụng một nửa đầu ra. Điều này làm cho sơ đồ giống hệt với việc derivate key được gia cố trong BIP32.
Kỹ thuật sử dụng seed làm định dạng key mặc định được NIST hỗ trợ tại đây
Triển khai Tham chiếu
Việc triển khai ví HD lưới nằm ở đây. Chúng tôi kiểm tra so với các vector kiểm tra được tạo bởi pq-crystals, là triển khai tham chiếu của dilithium, được viết bằng C bởi các tác giả của tiêu chuẩn.
Cả hai phiên bản ví đều sử dụng thư viện rust bip39 để chuyển từ một seed phrase mnemonic thành một "seed". Sau đó chúng ta derivate một "key chính" từ seed thông qua HMAC-SHA512 và đó tạo thành gốc của cây key, với mỗi cạnh đại diện cho HMAC-SHA512(R || 0x00 || L || child_index) trong đó L || R là các giá trị được chia của nút cha trong cây, như được mô tả trong tiêu chuẩn BIP32.
Lý do
Ban đầu chúng tôi cân nhắc sử dụng Falcon, vì nó có key và chữ ký nhỏ hơn. Để làm điều này, chúng tôi dựa vào việc triển khai rust-fn-dsa của Thomas Pornin về thuật toán chữ ký FALCON, với một số sửa đổi nhỏ để cho phép entropy được tạo bên ngoài. Thomas Pornin là một trong những tác giả của tiêu chuẩn FALCON và cũng là tác giả của việc triển khai PQClean C-lang của thuật toán. Việc triển khai ví Falcon nằm ở đây.
Sau đó chúng tôi được biết (từ Thomas Pornin) rằng tiêu chuẩn Falcon không hoàn toàn xác định con đường tạo key, vì vậy chúng tôi đã quyết định chuyển sang ml-dsa (trước đây là dilithium). Dilithium có một số ưu điểm. Nó
- đơn giản hơn
- nhanh hơn
- có tạo key xác định
- đã được NIST hoàn thiện
Các nhược điểm là key lớn hơn, chữ ký lớn hơn và việc xác minh chậm hơn.
Trong mọi trường hợp, các key và chữ ký lưới đều lớn hơn nhiều so với đường cong elliptic, vì vậy chúng ta sẽ phải trả giá bằng nhiều không gian đĩa hơn.
Cả Dilithium và Falcon đều yêu cầu <= 64 byte entropy làm đầu vào cho quá trình tạo key, vì vậy chúng ta có thể đơn giản sử dụng 32 byte đầu tiên của đầu ra HMAC-SHA512 làm nguồn entropy. Trường hợp sử dụng không được gia cố rõ ràng không thể đạt được với mật mã lưới, vì vậy chúng tôi bỏ qua nó.
Về mặt an ninh lượng tử của HMAC-SHA512, cuộc tấn công lượng tử chính chống lại các hàm hash là thuật toán Grover cung cấp tốc độ tăng gấp đôi khi tìm kiếm các cơ sở dữ liệu không được sắp xếp (tiền ảnh hash trong trường hợp của chúng tôi). Điều này làm giảm số bit bảo mật một nửa, vì vậy 512 → 256, 256 → 128, v.v. Điều này áp dụng cho tất cả các hàm hash, vì vậy bất kỳ thuật toán hash nào an toàn về mặt cổ điển đều sẽ có vấn đề tương tự. Mặt khác, đã được chứng minh rằng thuật toán Grover về mặt tiệm cận là tối ưu, vì vậy chúng ta không nên mong đợi một thuật toán lượng tử khác sẽ làm tốt hơn nhiều so với Grover chống lại một hàm hash an toàn.
Trái ngược với các hàm hash, các chữ ký số của blockchain rất dễ bị tấn công lượng tử, vì thuật toán Shor làm giảm độ khó tìm key riêng đường cong elliptic từ key công khai từ cấp số mũ (Pollard's rho) xuống đa thức logarit O(log^3(n)), trong đó n là số bit.
Vì lý do này, chúng tôi ưu tiên bảo mật các chữ ký số chống lại các cuộc tấn công lượng tử và để nguyên các hàm hash.
Bản quyền
Thông số kỹ thuật này được phát hành vào miền công cộng.
Xem sơ đồ này để tóm tắt BIP32.
Đề xuất này ban đầu được đăng như một Đề xuất Cải tiến Quantus tại đây
