Đây là một câu hỏi mặc dù đang lướt qua giới hạn của các cuộc chiến meta/chính trị trong cộng đồng mật mã.
SafeCurves là một tài nguyên tốt, nhưng nó rất ý kiến về ý nghĩa của "an toàn".
như một ví dụ secp256k1, đường cong được Bitcoin và Ethereum sử dụng để đảm bảo tính bảo mật của chúng bị nhóm SafeCurves coi là "không an toàn", trong khi nó hiện có hơn 1000 B$ "tiền thưởng tìm lỗi" dưới dạng BTC và ETH có thể bị hack nếu bạn có thể phá vỡ nó...
Vì vậy, không, không phải vì SafeCurves nói điều gì đó không "an toàn"điều đó có nghĩa là nó"vỡ". Đường cong NIST có thể tốt hơn, chắc chắn rồi, nhưng chúng vẫn hoạt động và thực hiện công việc của mình và (theo như chúng tôi biết) không có cuộc tấn công thực tế, hiệu quả nào chống lại chúng có thể đe dọa các hệ thống hiện đang sử dụng chúng, miễn là chúng được triển khai "đúng cách" ...
Nghĩa là chúng không bị hỏngvà cá nhân tôi sẽ không nói rằng chúng không "an toàn" để sử dụng vào năm 2021. Nhưng nếu tôi đang thiết kế một hệ thống mới nơi tôi có thể chọn bất kỳ cơ chế thỏa thuận khóa hoặc thuật toán chữ ký nào, thì chúng cũng không phải là lựa chọn đầu tiên của tôi.
Tôi e rằng một vấn đề lớn khi bạn đang làm việc trong lĩnh vực phát triển phần mềm (và phần cứng) là "tuân thủ" và NIST là tổ chức ban hành các "tiêu chuẩn" được coi là chén thánh trong thế giới tuân thủ.
Vì vậy, trong khi họ hiện đang làm việc trên các bản nháp mới (ví dụ: dự thảo cho FIPS 186-5 hiện đang bao gồm Ed25519 dưới dạng thuật toán chữ ký) chứa nhiều đường cong "hiện đại" hơn, họ vẫn chưa cập nhật các đề xuất và tiêu chuẩn của mình và do đó, nhiều thực thể bắt buộc phải dựa vào các đề xuất cũ tốt của họ, chẳng hạn như đường cong P-256.
Khả năng tương thích cũng là một vấn đề lớn. Ví dụ: đường cong NIST P-256 được hỗ trợ bởi Web Crypto API, phải là đường cong liên tục và "an toàn" (theo nghĩa "chúng tôi không biết các cuộc tấn công thực tế, hiệu quả chống lại nó"). Trong khi đó, Curve25519 hiện đại hơn được coi là an toàn hơn và ít bị lỗi triển khai hơn P-256, nhưng nó chưa được Web Crypto API hỗ trợ. Vì vậy, để thực hiện nội dung JavaScript bằng ECC, hiện tại bạn nên sử dụng P-256 thay vì Curve25519. (Hoặc WASM, nhưng đó là một chủ đề khác.)
Ngoài ra, điều quan trọng cần lưu ý là GnuPG đang tuân theo Thông số kỹ thuật OpenPGP và đang cố gắng trở thành một công cụ tương thích với nhau, có khả năng tương tác rộng rãi. Do đó, nó hỗ trợ RẤT NHIỀU lược đồ khác nhau, trong đó một số lược đồ cũ hơn các lược đồ khác, một số ít được sử dụng.
Có một dự thảo bao gồm hỗ trợ Ed25519 và X25519 trong PGP hiện đang mở và đã được tích cực làm việc trong vài năm qua:
Các vấn đề tương thích tương tự cũng phát sinh với PGP: nếu bạn muốn có thể dễ dàng giao tiếp với những người khác bằng cách sử dụng nó, thì tốt nhất là sử dụng thứ gì đó mà những người khác cũng đang sử dụng/hỗ trợ.
Vì vậy, PGP sẽ đạt được điều đó vào một lúc nào đó, nhưng đó là một quá trình chậm và miễn là các đường cong và tiêu chuẩn cũ này không thực tế (hoặc có nguy cơ bị) phá vỡ, thì quá trình chậm chạp này có thể sẽ không tăng tốc.
Bây giờ, bạn có nên thay đổi các khóa PGP của mình nếu bạn đang sử dụng P-256 hoặc một đường cong khác có "chi phí cho rho" cao hơn 2^100 trong danh sách đó: https://safecurves.cr.yp.to/rho.html ?
Tôi sẽ nói không". Hiện tại bạn không cần lo lắng, ít nhất là trong 5 năm tới, có thể hơn nữa. Nhưng mà Máy tính lượng tử có thể thay đổi câu chuyện này trong một vài năm nữa nếu chúng có hiệu quả như chúng ta mong đợi trong việc phá vỡ bài toán logarit rời rạc trong thực tế.
