Điểm:4

Có thể sử dụng chữ ký số để tạo khóa mã hóa AES không?

lá cờ gf
cjd

Tôi đang xem liệu sử dụng chữ ký điện tử có phải là cách an toàn và hợp lý để tạo khóa mã hóa AES hay không.

Dòng chảy sẽ như sau:

Người dùng ký một tin nhắn tôi với khóa riêng của họ. Họ thực sự ký tên băm của tôi nhưng điều này được đảm nhận như một phần của chức năng tạo chữ ký điện tử. Điều này trả về chữ ký số S.

Cung cấp S vẫn còn bí mật, là S một thông báo an toàn để sử dụng để tạo khóa k cho AES.

Họ chìa khóa k sẽ được tạo như sau:

const tiền điện tử = yêu cầu ('tiền điện tử');

crypto.scrypt(s, 'unique-salt', keyLength, (err, key) => {
    console.log(key.toString('hex')); // 12dd454fb...
});

Trong đó tham số đầu tiên của hàm S là chữ ký điện tử do người dùng tạo ra.

Tài liệu về gói tiền điện tử Node không đưa ra bất kỳ yêu cầu cụ thể nào đối với tham số này.

Tôi hiểu rằng nếu người khác lấy được chữ ký số thì người đó có thể giải mã và mã hóa tin nhắn, tuy nhiên cũng có thể nói như vậy nếu người đó lấy được bất kỳ chuỗi nào được sử dụng làm tham số đó.

Vì vậy, hai câu hỏi là:

  1. Đây có phải là cách an toàn và phù hợp để tạo khóa cho AES không? Giả sử rằng chữ ký điện tử là duy nhất và khó đoán bởi những người không có quyền truy cập vào khóa riêng. Và giả sử rằng chữ ký điện tử dùng để tạo khóa được giữ kín.

  2. Là bảo mật phụ thuộc vào tin nhắn tôi đó được ký kết? Điều này cũng cần phải được giữ bí mật? Giả định của tôi là thông báo là gì không quan trọng vì ngay cả khi mallet biết thông báo này thì họ cũng không thể tạo chữ ký điện tử chính xác vì họ không có khóa riêng.

Cảm ơn bạn

poncho avatar
lá cờ my
Bạn có cần chia sẻ khóa AES đó với người không biết khóa riêng của chữ ký không (hoặc hệ thống chữ ký không xác định - nghĩa là chữ ký được tạo thay đổi mỗi khi bạn tạo, ngay cả đối với cùng một thư)? Nếu bạn làm như vậy và bạn có một phương tiện vận chuyển an toàn phù hợp, liệu giải pháp thay thế chỉ chọn một khóa AES hoàn toàn ngẫu nhiên có hoạt động không?
Maarten Bodewes avatar
lá cờ in
@poncho Đối với (EC)DSA, tôi đoán bạn có $r$ ngẫu nhiên có thể được chia sẻ công khai. Tương tự, bạn có thể chia sẻ hạt giống hoặc hạt giống được tạo ngẫu nhiên cho RSA-PSS, giống như muối cho KDF. Vì vậy, tôi không chắc rằng một chức năng xác định là một yêu cầu, chỉ là bạn có thể tìm thấy một triển khai cho phép bạn đưa vào các giá trị ngẫu nhiên.
Maarten Bodewes avatar
lá cờ in
Tôi nghĩ rằng câu hỏi đặt ra là: việc tạo chữ ký có thể được sử dụng làm hàm dẫn xuất khóa (KDF) hay không.
poncho avatar
lá cờ my
@MaartenBodewes: đối với (EC)DSA, xuất bản hai chữ ký khác nhau có cùng $r$ là một ý tưởng **BAD**; Tôi sẽ tránh xa điều đó. Mặt khác, có các phiên bản xác định an toàn của (EC)DSA
Maarten Bodewes avatar
lá cờ in
@poncho Tôi không gợi ý điều đó. Tôi đang nói rằng bạn có thể sử dụng một giá trị ngẫu nhiên cho một dẫn xuất khóa/chữ ký duy nhất và sau đó lấy $r$ (xin lỗi, có thể là $k$) để tạo cùng một giá trị bằng cách sử dụng khóa riêng *và cùng một thông báo*. Rõ ràng là bạn nên giữ bí mật giá trị của $s$ nếu thông báo có thể thay đổi (đó là ý tưởng từ lâu nếu tôi không nhầm). Nhưng khi bạn có khóa đối xứng, bạn vẫn có thể sử dụng giá trị MAC để đảm bảo rằng cả hai bên đều có cùng một khóa.
cjd avatar
lá cờ gf
cjd
@poncho nên không. Người duy nhất sẽ giải mã dữ liệu sẽ là người dùng đã mã hóa dữ liệu ban đầu và sở hữu khóa riêng. Như vậy có được không?
cjd avatar
lá cờ gf
cjd
@MaartenBodewes, khóa vẫn sẽ được lấy từ chức năng scryprt. Nhưng chữ ký được sử dụng làm mật khẩu bí mật cho khóa chung.
Maarten Bodewes avatar
lá cờ in
Tôi đã thấy điều đó trong thực tế đối với chức năng tạo chữ ký RSA bằng cách sử dụng phần đệm PKCS#1 v1.5. Tất nhiên, điều đó không có nghĩa là nó an toàn;) Điều tồi tệ: nếu bạn muốn cấp bằng sáng chế cho kế hoạch của mình thì ít nhất bạn cũng đã trễ 20 năm rồi...
Điểm:3
lá cờ in

Có, bạn có thể sử dụng nó. Theo định nghĩa, kẻ tấn công sẽ không thể đưa ra chữ ký trên không tí nào tin nhắn cụ thể mà không cần khóa riêng. Vì vậy, nếu đúng như vậy thì chữ ký thực sự có thể được sử dụng làm khóa đối xứng và tôi biết một trường hợp nó được sử dụng như vậy (hoặc ít nhất là bí mật, thay vì khóa bí mật).

Tuy nhiên, bạn nên cẩn thận khi làm như vậy. Một số thuật toán chữ ký là không xác định và điều đó có thể làm phức tạp mọi thứ. Trong trường hợp xấu nhất, nó có thể làm cho thuật toán chữ ký hoàn toàn không an toàn. Tốt nhất, bạn có thể phải thay đổi thói quen tạo chữ ký để đưa vào một hạt giống hoặc giá trị ngẫu nhiên. Nó cũng sẽ yêu cầu bạn lưu trữ hạt giống hoặc giá trị ngẫu nhiên đó và điều đó có thể đi ngược lại yêu cầu trường hợp sử dụng của bạn. Lưu ý rằng nếu bất cứ điều gì về việc tạo số ngẫu nhiên bị thay đổi - thuật toán, cơ chế trích xuất hoặc trích xuất số nguyên - thì bạn có thể sẽ nhận được khóa sai (và vâng, tôi đã thấy điều này xảy ra).

Tuy nhiên, nếu bạn sử dụng phiên bản RSA xác định (đệm PKCS#1 v1.5) hoặc ECDSA xác định thì bạn sẽ ổn thôi.


Tuy nhiên, bạn có quyền sử dụng KDF sau dữ liệu. Khóa đối xứng phải trích xuất tất cả tính ngẫu nhiên trong chữ ký để được bảo mật (có thể theo sau là mở rộng khóa để có kích thước phù hợp, nhưng điều đó thường không bắt buộc).

mật mã tuy nhiên thường được sử dụng trên mật khẩu. Điều đó tốt, nhưng có lẽ bạn không cần muối hoặc yếu tố công việc để kéo dài khóa (vì dù sao mức độ ngẫu nhiên trong chữ ký cũng phải đủ cao). Vì vậy, nó là tốt nếu mật mã là bắt buộc, nhưng thông thường bạn muốn sử dụng KBKDF chẳng hạn như HKDF hoặc chỉ HKDF-Extract.

Nếu bạn có quyền truy cập vào giá trị khóa riêng, bạn cũng có thể sử dụng KDF trên đó.


Tôi chắc chắn khuyên bạn nên sử dụng thuật toán tạo chữ ký ít nhất có cùng độ mạnh với khóa đối xứng. Tất nhiên, điều tương tự cũng xảy ra với chức năng KDF; bạn có thể tìm thấy chi tiết tại keylength.com.

Hơn nữa, bạn có thể muốn lưu ý rằng mật mã đối xứng khó bị tấn công bằng một máy tính lượng tử chính thức, trong khi các thuật toán bất đối xứng thì không (mặc dù sơ đồ này có thể khó bị tấn công hơn so với sơ đồ tạo chữ ký chung, tùy thuộc vào cách nó được sử dụng ).


Tuy nhiên, một lưu ý triển khai khác: các chức năng tạo chữ ký không yêu cầu bạn giữ bí mật chữ ký. Chẳng hạn, một mô-đun phần cứng có thể giữ một khóa đối xứng dẫn xuất thông thường bên trong HSM. Mặt khác, nó có thể xuất chữ ký mà không gặp rắc rối vì giá trị chữ ký là giả sử để được công khai.

Các cuộc tấn công kênh bên vào giá trị chữ ký cũng có thể xảy ra, thật khó để nói trước. Vì vậy, mặc dù về mặt lý thuyết, kế hoạch này hợp lý, nhưng vẫn rất không nên làm như vậy trừ khi không còn cách nào khác.

cjd avatar
lá cờ gf
cjd
Điều đó thật tuyệt! Thực sự đánh giá cao câu trả lời chi tiết. Cảm ơn bạn.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.