Tôi chỉ đọc bài viết này RSA keys under 1024 bits are blocked và trong phần mềm .NET của tôi, tôi sử dụng rộng rãi các khóa 384bit. Chương trình của tôi vẫn có thể tạo/lưu/đọc các khóa từ MachineKeyStore bằng RSACryptoServiceProvider? Hay tôi buộc phải gửi một bản vá?. Net: Các khóa RSA của tôi vẫn hoạt động sau tháng 8 năm 2012?
Đây là câu trả lời được đề xuất cho câu hỏi được đưa ra trong nhận xét.
Bạn có thể tìm cách sử dụng phương pháp đối xứng để xác thực khách hàng. Tôi giả sử ngay bây giờ bạn đang sử dụng một lược đồ ký RSA điển hình, trong đó một băm tin nhắn được ký bởi một khóa riêng của khách hàng, sau đó nó có thể được xác minh bằng khóa công khai.
Bạn có thể thực hiện trao đổi khóa liên tục và sau đó mã hóa thông báo thông báo bằng khóa đó thay vì khóa không đối xứng. Bạn sẽ vẫn được đảm bảo rằng bất cứ ai đã gửi tin nhắn đều biết khóa bí mật, mặc dù bạn sẽ không có cách nào để xác minh xem thư có được gửi bởi máy khách hay máy chủ (vì cả hai đều biết khóa). Nếu khách hàng thách thức máy chủ trong quá trình xác thực, điều đó sẽ giúp ngăn chặn người đàn ông trong các cuộc tấn công giữa (mặc dù khách hàng sẽ cần phải có khóa công khai của máy chủ được nhúng cục bộ)
Tôi đánh giá cao đề xuất của bạn, nhưng nó không liên quan gì đến câu hỏi ban đầu. Nó sẽ là một nhiệm vụ lớn để thuyết phục tất cả người dùng của tôi nâng cấp trước tháng 8 năm 2012, vì vậy tôi không thay đổi mã hoặc lược đồ mã hóa. Bên cạnh đó, hệ thống là phong nha, giống như email, vì vậy khách hàng không thể lưu trữ một danh sách cố định của khóa công khai, họ phải được chuyển cùng với thông điệp. Sau đó, họ có thể chọn để đưa vào danh sách trắng các khóa nhất định, để bất cứ khi nào họ nhận được một thư khác, có thể yên tâm rằng đó là từ cùng một người gửi như trước đây. – Muis
Nếu giảm thiểu kích thước chữ ký là rất quan trọng, thì RSA kém lựa chọn để bắt đầu. DSA và ECDSA đều tạo ra chữ ký ngắn hơn với sức mạnh lớn hơn nhiều mà RSA. Tuy nhiên, cả DSA hoặc ECDSA sẽ không đạt được tốc độ xác minh chữ ký cho RSA 384.
Nếu bạn phải tiếp tục sử dụng các khóa bạn có thì bạn sẽ phải thay đổi mã để tránh sử dụng các API mã hóa của Microsoft. Bạn có thể sử dụng ví dụ thư viện Bouncycastle C# nếu bạn sử dụng C#. Cuối cùng, bạn có thể khiếu nại với Microsoft về điều này. Tôi nghi ngờ nó sẽ làm tốt nhưng bạn luôn có thể thử.
Khiếu nại chính của tôi là họ đã thông báo điều này chỉ 1 tháng trước khi họ thực hiện thay đổi đột phá này. Tôi có một cơ sở được cài đặt gần nửa triệu người dùng và không có chức năng tự động cập nhật, do đó sẽ không có cách nào để đảm bảo mọi người được nâng cấp trước khi bản vá được truy cập. – Muis
@Joshua Tôi nghe bạn. –
Lưu ý rằng tạo khóa và quan trọng hơn, việc tạo chữ ký nhanh hơn rất nhiều khi sử dụng ECDSA so với khóa RSA có cường độ tương tự. Vì vậy, nó phụ thuộc vào giao thức và tổng số hệ thống có lợi nhất. –
tôi nhận được trả lời từ Microsft (Kurt L Hudson), và bản cập nhật này chỉ ảnh hưởng đến chainbuilding, vì vậy nó có vẻ RSACryptoServiceProvider sẽ tiếp tục hoạt động với keysizes nhỏ sau ngày năm 2012.
Theo bài viết được liên kết, mọi thứ sử dụng chức năng xây dựng chuỗi bị ảnh hưởng, bao gồm SSL và S/MIME (aka CMS). Những người dùng khác có kích thước khóa nhỏ nên kiểm tra giao thức và chức năng nào họ sử dụng. –
wow nhờ đã làm cho tôi nhận thấy điều này. – ericosg
Rất có thể bạn sẽ gặp rắc rối (nếu không có bản vá này thì một trong những bản tiếp theo), nhưng mã hiện tại của bạn thiếu sót ở nơi đầu tiên: khóa RSA 384 bit là WEAK và bạn phải cân nhắc cập nhật chúng lên ít nhất 1024 bit ASAP không chờ đợi các bản vá lỗi của Microsoft. –
Bạn có thể mở khóa 384 bit trên máy tính để bàn trong vài ngày. Hoặc đã là tuần. – Wug