Có, việc tạo chữ ký ECDSA từ tin nhắn là điều bình thường $M$ (hoặc đó là hàm băm $H(M)$ ), khóa riêng $d_U$ và các tham số đường cong, mà không được cung cấp nonce làm đầu vào. nonce $k$ được xây dựng như một phần của quy trình ký, theo một trong hai cách:
- Nó tạo ra một số nguyên bí mật $k$ thống nhất trong $[1,n)$ sử dụng trình tạo số ngẫu nhiên thực với đầu ra bí mật. đó là định nghĩa tiêu chuẩn của ECDSA.
- Nó tạo ra một số nguyên bí mật $k$ Trong $[1,n)$ sử dụng một Chức năng giả ngẫu nhiên cùng với chìa khóa $d_U$, áp dụng cho $H(M)$ và các dữ liệu tùy chọn khác không cần bí mật (chẳng hạn như dấu thời gian hoặc/và một số ngẫu nhiên). Đó là gì RFC6979 hiện, kê đơn PRF dựa trên HMAC.
Cả hai phương pháp đều an toàn: về bản chất, $k$ là một bí mật trong $[1,n)$ điều đó, đối với những kẻ tấn công không biết khóa riêng $d_U$, không xác định và, nếu đã biết, sẽ xuất hiện ngẫu nhiên (ngoại trừ tùy chọn thứ hai nếu giống nhau $M$ được ký lại và dữ liệu tùy chọn khác lặp lại hoặc không có).
Phương pháp thứ hai có ưu điểm là không yêu cầu bộ tạo số ngẫu nhiên thực sự có chất lượng mật mã. Tuy nhiên, nó sử dụng khóa riêng $d_U$ (và tệ hơn là trộn nó với dữ liệu thay đổi mà kẻ thù có thể biết), do đó PRF phải được bảo vệ trước các cuộc tấn công kênh phụ.
Chỉ có phương pháp thứ hai mới có thể đảm bảo rằng việc ký cùng một thông điệp hai lần bằng cùng một khóa riêng tư sẽ tạo ra cùng một chữ ký, điều này tùy thuộc vào hoàn cảnh có được mong muốn hay không.
