Thứ Ba, 30 tháng 12, 2014

Schneier nói về an toàn


Crypto-Gram Newsletter (Thư tin mật mã)

15/09/1999
của Bruce Schneier
Người sáng lập và Giám đốc Công nghệ của hãng Counterpane Internet Security
Một thư tin tự do hàng tháng đưa ra các tóm tắt, các phân tích, sự hiểu thấu, và các bình luận về an toàn và mật mã máy tính.
Các xuất bản phẩm trước kia có sẵn ở http://www.schneier.com. Để đăng ký hoặc bỏ đăng ký, xem bên dưới.
Copyright (c) 1999 by Bruce Schneier


Trong số này:


Lời người dịch: Bruce Schneier, người thường xuyên được chính phủ liên bang tư vấn về các vấn đề an toàn, từ năm 1999 đã nói rằng: “Trong thế giới mật mã, chúng tôi xem nguồn mở là cấp thiết cho an toàn tốt; chúng tôi có hàng chục năm rồi. An toàn công khai luôn an toàn hơn so với an toàn sở hữu độc quyền. Điều này đúng cho các thuật toán mật mã, các giao thức an toàn, và mã nguồn an toàn. Đối với chúng tôi, nguồn mở không chỉ là một mô hình kinh doanh; nó là thực tiễn kỹ thuật thông minh”. Về mật mã nguồn mở, Bruce Schneier nói: “Mật mã từng song hành với các ý tưởng nguồn mở hàng chục năm, dù chúng tôi gọi nó là “sử dụng các thuật toán và giao thức công khai”. Ý tưởng là đơn giản: mật mã là khó để làm đúng, và cách duy nhất để biết liệu có điều gì đó đã được làm đúng hay không là phải có khả năng kiểm tra nó”.

Nguồn mở và an toàn

Như một chuyên gia về mật mã học và an toàn máy tính, tôi không bao giờ hiểu được sự ồn ào hiện hành đối với phong trào phần mềm nguồn mở. Trong thế giới mật mã, chúng tôi xem nguồn mở là cấp thiết cho an toàn tốt; chúng tôi có hàng chục năm rồi. An toàn công khai luôn an toàn hơn so với an toàn sở hữu độc quyền. Điều này đúng cho các thuật toán mật mã, các giao thức an toàn, và mã nguồn an toàn. Đối với chúng tôi, nguồn mở không chỉ là một mô hình kinh doanh; nó là thực tiễn kỹ thuật thông minh.

Mật mã nguồn mở

Mật mã từng song hành với các ý tưởng nguồn mở hàng chục năm, dù chúng tôi gọi nó là “sử dụng các thuật toán và giao thức công khai”. Ý tưởng là đơn giản: mật mã là khó để làm đúng, và cách duy nhất để biết liệu có điều gì đó đã được làm đúng hay không là phải có khả năng kiểm tra nó.

Điều này là sống còn trong mật mã, vì an toàn không có điều gì phải làm với chức năng cả. Bạn có thể có 2 thuật toán, một an toàn và một không an toàn, và chúng đều có thể làm việc tuyệt vời. Chúng có thể mã hóa và giải mã, chúng có thể là có hiệu lực và có một giao diện người sử dụng khá đẹp, chúng có thể không bao giờ gãy. Cách duy nhất để nói mật mã tốt từ mật mã xấu là để cho nó được kiểm tra.

Thậm chí tồi tệ hơn, không có bất kỳ điều gì tốt lành hơn là để có một đám người ngẫu nghiên kiểm tra mã đó; cách duy nhất để nói mật mã tốt từ mật mã xấu là phải để cho nó được các chuyên gia kiểm tra. Việc phân tích mật mã là nặng nhọc, và có rất ít người trên thế giới có thể có năng lực làm nó. Trước khi một thuật toán có thể thực sự được xem là an toàn, nó cần phải được nhiều chuyên gia kiểm tra trong quá trình nhiều năm.

Điều này lập luận rất mạnh mẽ cho các thuật toán mật mã nguồn mở. Vì cách duy nhất để có bất kỳ lòng tin nào trong sự an toàn của một thuật toán là phải nhờ các chuyên gia kiểm tra nó, và cách duy nhất họ sẽ bỏ thời gian cần thiết để kiểm tra nó một cách đúng đắn là phải cho phép họ xuất bản các tài liệu nghiên cứu về nó, thuật toán phải là công khai. Một thuật toán sở hữu độc quyền, bất kể là ai đã thiết kế ra nó và ai được trả tiền theo NDA để đánh giá nó, là rủi ro hơn nhiều so với một thuật toán công khai.

Lý lẽ phản biện mà bạn đôi khi nghe là mật mã bí mật là mạnh hơn vì nó là bí mật, và các thuật toán công khai là rủi ro hơn vì chúng là công khai. Điều này nghe có vẻ hợp lý, cho tới khi bạn nghĩ về nó trong một phút. Các thuật toán công khai được thiết kế để là an toàn thậm chí dù chúng là công khai; đó là cách mà chúng được làm ra. Vì thế không có rủi ro trong việc làm cho chúng công khai. Nếu một thuật toán chỉ an toàn nếu nó giữ được là bí mật, thì nó sẽ chỉ là an toàn cho tới khi ai đó tiến hành kỹ thuật nghịch đảo và xuất bản các thuật toán đó. Sự đa dạng của các thuật toán điện thoại cầm tay số bí mật đã từng “bật bãi” và nhanh chóng bị gãy, minh họa cho tính phù phiếm của lý lẽ đó.

Thay vì sử dụng các thuật toán công khai, các công ty điện thoại cầm tay số của Mỹ đã quyết định tạo mật mã sở hữu độc quyền của riêng họ. Trong ít năm qua, các thuật toán khác nhau đã được làm công khai. (Không, nền công nghiệp điện thoại cầm tay đã không muốn chúng được làm thành công khai. Những gì thường xảy ra là một nhà mật mã học nhận được một đặc tả bí mật trong một bao hoàn toàn màu tối). Và một khi chúng được làm thành công khai, chúng đã bị gãy. Bây giờ nền công nghiệp điện thoại cầm tay của Mỹ đang cân nhắc các thuật toán công khai để thay thế các thuật toán sở hữu độc quyền bị gãy của họ.

Mặt khác, chương trình mã hóa thư điện tử phổ biến PGP đã luôn sử dụng các thuật toán công khai. Và không thuật toán nào trong đó từng bị gãy cả. Điều y hệt là đúng đối với các giao thức mật mã Internet khác nhau: SSL, S/MIME, IPSec, SSH, và cứ thế.

Tiền không mua được sự đánh giá tốt nhất

Ngay bây giờ chính phủ Mỹ đang chọn một thuật toán mã hóa để thay thế cho DES, được gọi là Tiêu chuẩn Mã hóa Tiên tiến - AES (Advanced Encryption Standard). Có 5 đối thủ đối với tiêu chuẩn đó, và trước khi tiêu chuẩn cuối cùng được các nhà mật mã học giỏi nhất thế giới chọn sẽ bỏ ra hàng ngàn giờ đánh giá chúng. Không công ty nào, bất kể giàu có tới đâu, có thể kham được dạng đánh giá đó. Và vì AES là tự do cho tất cả sử dụng, không có lý do gì cho một công ty thậm chí lo việc tạo ra tiêu chuẩn của riêng nó. Mật mã mở không chỉ tốt hơn - nó còn là rẻ hơn.

Lý do y hệt dẫn các các công thông minh sử dụng mật mã được xuất bản cũng dẫn họ tới sử dụng các giao thức an toàn được xuất bản: bất kỳ ai mà tạo ra giao thức an toàn của riêng mình hoặc là một thiên tài hoặc là một thằng ngu. Vì có nhiều thằng ngu hơn các thiên tài, nên việc sử dụng các giao thức được xuất bản chính là thông minh hơn.

Hãy xem xét IPSec, giao thức an toàn IP Internet. Bắt đầu trong năm 1992, nó đã được một ủy ban thiết kế mở và tuân theo sự soi xét công khai đáng kể từ đầu. Bất kỳ ai cũng đã biết nó từng là một giao thức quan trọng và mọi người đã bỏ ra nhiều nỗ lực cố gắng làm cho nó đúng. Các công nghệ an toàn đã được đề xuất, bị gãy, và sao đó được sửa đổi. Các phiên bản đã được lập trình và được phân tích. Bản phác thảo đầu tiên của tiêu chuẩn đó đã được xuất bản trong năm 1995. Các khía cạnh khác của IPSec đã được tranh luận về các giá trị về an toàn và về hiệu năng, sự dễ đàng triển khai, khả năng nâng cấp, và sử dụng.

Vào tháng 11/1998, ủy ban đó đã xuất bản một đống các yêu cầu gọi bình luận - RFC (Request For Comments) - một đống trong một loạt các bước để làm cho IPSec trở thành một tiêu chuẩn Internet. Và nó vẫn còn đang được nghiên cứu. Các nhà mật mã học ở Phòng thí nghiệm Nghiên cứu Hải quân gần đây đã phát hiện một lỗi nhỏ trong triển khai. Công việc tiếp tục, một cách công khai, cho bất kỳ ai và bất kỳ người nào có quan tâm. Kết quả, dựa vào nhiều năm phân tích công khai, là một giao thức mạnh mà được nhiều người tin cậy.

Mặt khác, Microsoft đã phát triển Giao thức Hầm ngầm Điểm - Điểm - PPTP (Point-to-Point Tunneling Protocol) của riêng hãng để làm nhiều điều y hệt. Họ đã sáng tạo ra giao thức xác thực của riêng họ, các hàm băm của riêng họ, và thuật toán sinh khóa của riêng họ. Từng trong số các khoản đó từng lỗi bét nhè. Họ đã sử dụng một thuật toán mã hóa nổi tiếng, nhưng họ đã sử dụng nó theo một cách mà phủ định an toàn của nó. Họ đã tiến hành triển khai các sai lầm đã làm suy yếu hệ thống thậm chí xa hơn. Nhưng vì họ đã làm tất cả công việc này trong nội bộ, không ai biết rằng PPTP là yếu.

Microsoft đã đưa PPTP vào Windows NT và 95, và đã sử dụng nó trong các sản phẩm mạng riêng ảo (VPN) của họ. Cuối cùng họ đã xuất bản các giao thức của họ, và vào mùa hè năm 1988, hãn mà tôi làm việc, Counterpane, đã xuất bản một tài liệu mô tả các lỗi mà chúng tôi đã thấy. Một lần nữa, sự soi xét công khai là hơn. Microsoft nhanh chóng đưa ra một loạt các bản sửa lỗi mà chúng tôi đã đánh giá vào mùa hè này và thấy được cải thiện, nhưng vẫn còn có lỗi.

Giống như các thuật toán, cách duy nhất để nói một giao thức an toàn tốt từ một giao thức bị gãy là phải để các chuyên gia đánh giá nó. Vì thế nếu bạn cần sử dụng một giao thức an toàn, bạn sẽ thông minh hơn nhiều lấy giao thức mà đã được đánh giá rồi. Bạn có thể tạo thứ của riêng bạn, nhưng đâu là những bất thường của nó như một giao thức an toàn mà đã được các chuyên gia đánh giá qua vài năm vừa rồi?

An toàn cho mã của bạn

Lý do chính xác y như vậy dẫn bất kỳ kỹ sư an toàn thông minh nào sẽ yêu cầu mã nguồn mở cho bất kỳ thứ gì có liên quan tới an toàn. Hãy rà soát lại: An toàn không có điều gì để làm với chức năng cả. Vì thế, không lượng kiểm thử beta nào có thể bao giờ đó phát hiện ra một lỗi về an toàn. Cách duy nhất để tìm thấy các lỗi về an toàn trong một mẩu mã - như trong một thuật toán mật mã hoặc một giao thức về an toàn - là phải đánh giá nó. Điều này là đúng cho tất cả các mã, bất kể nó là nguồn mở hay sở hữu độc quyền. Và bạn không thể chỉ nhờ ai đó đánh giá mã, mà bạn cần các chuyên gia về phần mềm an toàn đánh giá mã đó. Bạn cần họ đánh giá nó nhiều lần và từ nhiều góc độ khác nhau, qua một quá trình dài nhiều năm. Có khả năng để thuê dạng này của sự tinh thông, nhưng là rẻ hơn nhiều và hiệu quả hơn nhiều để cho cộng đồng rộng lớn làm điều này. Và cách tốt nhất để làm cho điều này xảy ra là xuất bản mã nguồn đó.

Nhưng sau đó nếu bạn muốn mã của bạn thực sự là an toàn, thì bạn sẽ cần làm nhiều hơn so với chỉ xuất bản nó theo một giấy phép nguồn mở. Có 2 sự thận trọng rõ ràng bạn nên giữ trong đầu.

Đầu tiên, đơn giản việc xuất bản mã không tự động có nghĩa là mọi người sẽ kiểm tra nó về các lỗi an toàn. Các nhà nghiên cứu an toàn là những người hay thay đổi và bận rộn. Họ không có thời gian để kiểm tra từng mẫu mã nguồn được xuất bản. Vì thế trong khi mở mã nguồn ra là một điều tốt, thì điều đó không là một sự đảm bảo về an toàn. Tôi có thể nêu tên một tá các thư viện an toàn nguồn mở mà không ai nghe thấy bao giờ, và không ai bao giờ đánh giá chúng cả. Mặt khác, mã an toàn trong Linux được xem xét với nhiều kỹ sư về an toàn rất tốt.

Thứ 2, bạn cần phải chắc chắn rằng các vấn đề về an toàn sẽ được sửa nhanh chóng khi được tìm thấy. Mọi người sẽ thấy các lỗi về an toàn trong mã an toàn của nguồn mở. Đây là điều tốt lành. Không có lý do để tin tưởng rằng mã nguồn mở là, vào thời điểm viết nó, là an toàn hơn so với mã sở hữu độc quyền. Điểm mấu chốt là làm cho nó thành nguồn mở sao cho nhiều, nhiều người xem xét mã đối với các lỗi về an toàn và tìm thấy chúng. Chúng sau đó phải được sửa. Vì thế một mẫu mã nguồn mở 2 năm tuổi có khả năng có ít hơn các lỗi về an ninh so với mã sở hữu độc quyền, đơn giản vì quá nhiều các lỗi trong số chúng đã được tìm thấy và được sửa theo thời gian. Các lỗi về an toàn cũng sẽ được phát hiện trong mã sở hữu độc quyền, nhưng với tốc độ chậm hơn nhiều.

So sánh an toàn của Linux với an toàn của Microsoft Windows là rất không đáng chỉ bảo. Microsoft đã làm một công việc dễ sợ như vậy với an toàn rằng thực sự không phải là một sự so sánh công bằng. Nhưng việc so sánh Linux với Solaris, ví dụ, là đáng chỉ bảo hơn. Mọi người đang tìm thấy các vấn đề về an toàn với Linux là nhanh hơn và chúng được sửa lỗi nhanh hơn. Kết quả là một hệ điều hành mà, thậm chí dù nó vừa chỉ mới được đưa ra ít năm trước, là lành mạnh hơn nhiều so với Solaris từng với ngần ấy tuổi.

PR về an toàn

Một trong những lợi ích của phong trào nguồn mở là tác động góp ý có tính xây dựng của sự công khai. Đi dạo trong bất kỳ một siêu thị máy tính nào những ngày đó, và bạn sẽ thấy một cái giá toàn bộ các sản phẩm dựa vào Linux. Mọi người mua chúng vì sự cuốn hút của Linux không còn chỉ giới hạn trong những người siêu về máy tính (geek); nó là một công cụ hữu dụng cho các ứng dụng nhất định. Vòng ý kiến phản hồi y hệt làm việc trong an toàn: các thuật toàn và các giao thức công khai giành được lòng tin vì mọi người biết chúng và sử dụng chúng, và sau đó chúng trở thành thứ thông dụng hiện hành. Những người marketing gọi điều này là nhận thức phổ biến. Nó không phải là một mô hình tuyệt hảo, nhưng, nó là tốt hơn so với các lựa chọn khác.

Khóa của NSA trong API mật mã của Microsoft?


Vài tháng trước, tôi đã nói chuyện về hệ thống của Microsoft dành cho việc ký số các bộ mật mã đi vào trong hệ điều hành của hãng. Điểm mấu chốt là chỉ các bộ mật mã được phê chuẩn có thể được sử dụng, làm cho điều giống như kiểm soát xuất khẩu được dễ dàng hơn. Thật là bực mình, đây là thị trường hiện hành.

Microsoft có 2 khóa, một khóa chủ và một khóa dự bị. Bài báo Crypto-Gram đã nói về các cuộc tấn công dựa vào sự việc là một bộ mật mã được xem là được ký nếu nó được khóa EITHER ký, và rằng không có cơ chế cho sự biến đổi từ khóa chủ sang khóa dự phòng. Đó là mật mã ngu xuẩn, nhưng kiểu đó thì bạn bạn có lẽ kỳ vọng thoát ra khỏi Microsoft.

Bỗng nhiên có một sự nhộn nhạo các hoạt động báo chí vì ai đó lưu ý rằng khóa thứ 2 trong Crypto API của Microsoft trong Windows NT Service Pack 5 được gọi là "NSAKEY" trong mã. À há! Cơ quan An ninh Quốc gia Mỹ - NSA (National Security Agency) có thể ký các bộ mật mã. Họ có thể sử dụng khả năng này để bỏ một bộ mật mã được Trojan hóa vào các máy tính của bạn. Hoặc vì thế thuyết âm mưu tồn tại.

Tôi không mua nó.

Thứ nhất, nếu NSA muốn làm tổn thương Crypto API của Microsoft, có thể là dễ dàng hơn nhiều để hoặc (1) thuyết phục MS nói cho họ khóa bí mật cho khóa chữ ký của MS, (2) để MS ký một module bị NSA làm tổn thương, hoặc (3) cài đặt một module khác với Crypto API để phá mã hóa (không module nào khác cần các chữ ký). Luôn là dễ dàng để phá mã hóa tốt bằng việc tấn công máy sinh số ngẫu nhiên hơn là việc ép buộc thô thiển cái khóa.

Thứ 2, NSA không cần một khóa để làm tổn thương an toàn trong Windows. Các chương trình như Back Office có thể làm điều này mà không cần bất kỳ khóa nào. Việc tấn công Crypto API vẫn đòi hỏi rằng nạn nhận chạy một tệp thực thi (thậm chí một macro của Word) trên máy tính của anh ta. Nếu bạn có thể thuyết phục một nạn nhân để chạy một macro không tin cậy, thì có hàng ngàn tỷ cách thông minh hơn để làm tổn thương sự an toàn.

Thứ 3, vì sao trên thế giới có thể ai đó gọi một khóa bí mật của NSA là “NSAKEY” nhỉ? Nhiều người có sự truy cập tới mã nguồn bên trong Microsoft; một âm mưu như thế này chỉ có thể được ít người biết. Bất kỳ ai với một trình gỡ lỗi cũng có thể thấy khóa “NSAKEY” này. Nếu điều này là một cơ chế giấu giếm, thì nó không phải là giấu giếm lắm.

Tôi thấy có 2 khả năng. Một là, đó là khóa sao lưu như Microsoft nói, một khóa sao lưu. Nó được gọi là “NSAKEY” vì một lý do ngớ ngẩn nào đó, và chỉ có thế.

Hai là, đó thực sự là một khóa NSA. Nếu NSA sẽ sử dụng các sản phẩm của Microsoft cho giao thông bí mật, thì họ sẽ cài đặt mật mã của riêng họ. Họ sẽ không muốn chỉ ra nó cho bất kỳ ai, thậm chí không cả cho Microsoft. Họ sẽ muốn ký các module của riêng họ. Vì thế khóa sao lưu cũng có thể là một khóa nội bộ của NSA, sao cho họ có thể cài đặt mật mã mạnh trong các sản phẩm của Microsoft để sử dụng nội bộ của riêng họ.

Nhưng đây không phải là một khóa NSA nên họ có thể bí mật tống mật mã yếu vào đám đông không nghi ngờ. Cũng có nhiều điều thông minh hơn họ có thể làm cho đám đông không nghi ngờ.

Bài báo gốc của tôi:

Tuyên bố:
http://www.cryptonym.com/hottopics/msft-nsa.html [liên kết chết từ ngày 18/02/2000]

Phân tích hay:

Bài báo tin tức hữu dụng:


Counterpane - Nghiên cứu tính năng

“Phân tích mật mã các mở rộng xác thực PPTP của Microsoft (MS-CHAPv2)”

Bruce Schneier và Mudge, CQRE, Duesseldorf, tháng 10/1999, sẽ xuất hiện.

Giao thức Đường hầm Điểm - Điểm - PPTP (Point-to-Point Tunneling Protocol) được sử dụng để đảm bảo an toàn cho các kết nối PPP qua liên kết TCP/IP. Trả lời cho [SM98], Microsoft đã đưa ra các mở rộng cho cơ chế xác thực PPTP (MS-CHAP), gọi là MS-CHAPv2. Chúng tôi trình bày tổng quan về các thay đổi trong các phần xác thực và sinh khó mã hóa của MS-CHAPv2, và đánh giá những tiến bộ và những điểm yếu còn tồn tại trong triển khai PPTP của Microsoft. Trong khi việc sửa một số nhiều hơn các lỗi quá xá trong MS-CHAPv1, thì giao thức mới vẫn còn chịu vài điểm yếu y hệt.

Tin tức

Dự án Kiểm toán Internet. Đây là điều thú vị THỰC SỰ. Một nhóm đã kiểm toàn an toàn mức thấp đối với 36 triệu máy chủ host trên Internet. Thực sự thì Internet an toàn mức nào?

Và nếu điều đó không gây đủ sợ hãi, đây là một kiểm toán chi tiết hơn về 2200 site Internet.

Tôi luôn thích tuyên bố tuân thủ Y2K:
Nếu bạn cần nhiều bằng chứng hơn rằng an toàn sở hữu độc quyền đúng là không làm việc, thì định dạng an toàn nhạc số của Microsoft bị rạn nứt trong vài ngày sau khi được tung ra:

Tống tiền bằng sáng chế: Các luật sư đã nêu tên ai đó là Leon Stambler đã và đang gửi các bức thư đe dọa tới các công ty an toàn, nói rằng SSL, PCK, FIPS 196, SET, Microsoft PPTP, mã xác thực Authenticode, ..., vi phạm bằng sáng chế của anh ta. Hãy tự xem; các số bằng sáng chế Mỹ là 5,793,302 và 5,646,998.

Với tất cả câu chuyện về bầu cử điện tử, là thú vị để ai đó nhận thức được rằng có vài vấn đề nghiêm trọng về an toàn. Nghiêm trọng nhất, ít nhất đối với tôi, là sự ép buộc người bầu cử. Khi bạn bước vào phòng bầu cử riêng tư, bạn có thể bầu theo ý muốn. Không ai có thể làm bất kỳ điều gì về nó. Nếu bạn có thể bầu cử từ máy tính của bạn, trong căn nhà riêng của bạn, với vài dạng phương tiện an toàn điện tử, sau đó là có khả năng cho ai đó sẽ mua phiếu bầu của bạn và đảm bảo rằng bạn đang phân phối hàng hóa.

Nhiều người đã hỏi tôi về bình luận của tôi cho vấn đề gần đây nhất về việc Windows NT cần hơn 300 thay đổi về an toàn để làm cho nó an toàn. Tôi đã truy vấn nhóm tin Usenet comp.os.ms-windows.nt.admin.security hỏi liệu nó là chuyện nghiên cứu dân gian hay là sự thực, và nhận được vài câu trả lời. Sự đồng thuận dường như là con số đó nằm đâu đó giữa 50 và 3.000, và 300 không phải là một ước tính không hợp lý. Một danh sách kiểm tra tốt có sẵn ở đây:
và xem ở đây nữa:

Các qui định xuất khẩu mật mã của Mỹ đã dẫn tới sự phát triển một vài sản phẩm tuyệt vời từ các công ty không phải của Mỹ. Phán xét từ bài báo này, dù, đây không phải là một trong số chúng:

2 sách trắng về an toàn của Microsoft. Chúng không thật hay, nhưng chúng giải thích đường lối của Microsoft.
An toàn các Macro của Office 2000: http://officeupdate.microsoft.com/2000/... [liên kết được chuyển tới http://office.microsoft.com/downloads/2000/o2ksec.aspx]

Một lỗi trong Hotmail cho phép bất kỳ ai đọc bất kỳ thư nào của ai khác, không cần mật khẩu. Đối với tôi, câu chuyện thực sự thú vị không phải là lỗi đó đã không được tìm ra, mà nó có thể đã được cộng đồng thế giới ngầm biết được từ lâu trước khi nó trở nên công khai. Một vài câu chuyện tin tức ngụ ý điều này.

Thuật trạm trổ được mã hóa ở tổng hành dinh của CIA ở Langley, VA.

Hãy ra nhập quân đội và xem các trụ sở ở Ft. Meade. Cơ quan An ninh Quốc gia đang chào học bổng cao đẳng tự do và phòng học và bàn ăn cho các tin tặc muốn làm việc cho họ trong 5 năm sau khi tốt nghiệp.

Bài báo thú vị của BBC về tranh luận mã hóa của Mỹ:

Thứ buồn cười: câu chuyện thực tế về Alice và Bob:

Có một bài báo thực sự hay - rõ ràng, hoàn chỉnh, có thể hiểu được - Khoa học gần đây về điện toán lượng tử. Cryptome đã đưa bài đó lên trực tuyến, với sự cho phép của tác giả.

Tin tức đáng sợ thêm

Bộ Tư pháp có kế hoạch yêu cầu Quốc hội về nhà chức trách mới cho phép các đặc vụ liên bang được trang bị với các lệnh tìm kiếm để bí mật đột nhập vào các ngôi nhà và các văn phòng để có được các khóa giải mã hoặc các mật khẩu hoặc để cài cắm “các thiết bị phục hồi” hoặc nếu không thì sửa các máy tính để đảm bảo rằng bất kỳ thông điệp hoặc tệp được mã hóa nào cũng có thể được chính phủ đọc được.

Với đề nghị kịch tính này, chính quyền Clinton về cơ bản đang nói: “Nếu bạn không trao chìa khóa của bạn trước cho một bên thứ 3, thì chúng tôi sẽ bí mật đi vào ngôi nhà của bạn để lấy nó nếu chúng tôi nghi ngờ tiến hành tội phạm”.

Toàn văn của đề nghị đó của Bộ Tư pháp, một phân tích chi tiết từng phần được các luật sư của Bộ Tư pháp chuẩn bị, và các tư liệu có liên quan có sẵn tại:



Tin tức của Counterpane

Bruce Schneier sẽ nói chuyện tại SANS Network Security 99, ngày 3-10/10, ở New Orleans. Xem http://www.sans.org/ns99/ns99.htm để có thêm các chi tiết về hội nghị.

Cây tấn công: Thứ tư, 06/10, 10:30 – 12:30
Mật mã Internet: Thứ ba, 05/10, 9:00 – 5:00

Bruce Schneier là tác giả của chuyên mục “Bên trong các Rủi ro” cho các số tháng 8, 9 và 10/1999 của tạp chí Communications của ACM.
Sinh trắc học: sử dụng và lạm dụng: http://www.schneier.com/essay-insiderisks1.html
Cuộc đua của ngựa Trojan: http://www.schneier.com/essay-insiderisks2.html
Các rủi ro của việc dựa vào mật mã: http://www.schneier.com/essay-insiderisks3.html

Nhà tồi tàn: E*Trade


Mật khẩu của E*Trade là không an toàn. Chúng giới hạn mật khẩu đăng nhập tối đa 6 ký tự, và chỉ lựa chọn các ký tự (có phân biệt chữ hoa và chữ thường), các con số, dấu $, và dấu _. Hồ sơ của ai bạn muốn buôn bán ngày hôm nay?

Sản xuất số 512-bit

Một hồ sơ sản xuất đã bị bể vào tháng trước, hôm 22/08. Một nhóm đứng đầu là Hermante te Riele của CWI ở Amsterdam đã sản xuất một số cứng 512-bit (155-ký tự). Với chữ “cứng”, tôi ngụ ý rằng nó từng là sản phẩm của 2 số 78-chữ số đầu tiên ... dạng các số được thuật toán của RSA sử dụng.

Khoảng 300 máy trạm SGI nhanh và các máy tính cá nhân PC Pentium đã làm việc, hầu hết vào các buổi tối và ngày cuối tuần, trong quá trình dài 7 tháng. Thuật toán được sử dụng là General Number Field Sieve. Thuật toán đó có 2 phần: một bước sàng lọc và một bước giảm ma trận. Bước sàng lọc là phần mà 300 máy tính đã làm việc về nó: khoảng 8.000 MÍP-năm qua 3.7 tháng. (Đây là bước mà thiết bị TWINKLE của Shamir có thể tăng tốc). Bước giảm ma trận mất 224 giờ của CPU (và khoảng 3.2 GB bộ nhớ) trên máy Cray C916 ở Trung tâm Máy tính Hàn lâm Amsterdam - SARA. Nếu điều này đã được làm qua Internet thông thường, sử dụng các tài nguyên có khả năng so sánh được với những gì đã được sử dụng trong các nỗ lực phá DES gần đây, thì nó có thể mất thoeì gian theo lịch khoảng 1 tuần.

Toàn bộ nỗ lực từng 50 lần dễ hơn so với việc phá DES. Việc sản xuất các khóa thương mại điện tử hoàn toàn rất thực tế, và sẽ trở nên thậm chí hơn thế trong các năm sắp tới. Chắc chắn là hợp lý để kỳ vọng các số 768-bit sẽ được sản xuất trong vài năm, nên các bình luận từ các Phòng thí nghiệm của RSA rằng các khóa RSA sẽ là tối thiểu của 768 bit sẽ là lạc quan quá nhiều.

Certicom đã sử dụng sự kiện đó để chào các lợi ích của mật mã khóa công khai đường elip. Các thuật toán đường elip, không giống như các thuật toán như RSA, ElGamal và DSA, không bị tổn thương đối với các kỹ thuật toán học mà có thể tạo ra các số lớn đó. Vì thế, họ viện lý, các thuật toàn đường elip là an toàn hơn so với RSA và ... Có vài sự thật ở đây, nhưng chỉ nếu bạn chấp nhận lời hứa rằng các thuật toán đường elip có toán học khác cơ bản. Tôi đã viết về điều này trước đó; tóm tắt ngắn là bạn nên sử dụng mật mã đường elip nếu các cân nhắc bộ nhớ đòi hỏi nó, nhưng RSA với các khóa dài thì có thể an toàn hơn.

Sự kiện này là đáng kể vì 2 lý do. Một là, hầu hết các giao thức an toàn Internet sử dụng RSA 512-bit. Điều này có nghĩa là những người không chuyên về mật mã học sẽ lưu ý về điều này, và có thể lúng túng một chút. Và thứ 2 là, không giống như việc tạo ra các nỗ lực khác, điều này được một tổ chức bí mật làm. Hầu hết các nhà mật mã học thậm chí đã không biết nỗ lực này từng diễn ra. Điều này chỉ ra rằng các tổ chức khác có thể đang phá gãy rồi các khóa thương mại điện tử một cách thường xuyên, và chỉ không nói cho bất kỳ ai mà thôi.

Nhưng thường lệ, báo chí đang làm cho câu chuyện này thành sai. Họ nói những điều giống như là: “Các khóa 512-bit không còn an toàn nữa”. Điều này hoàn toàn là không đúng. Giống như nhiều câu chuyện mật mã đó, tin tức thực sự là không có tin tức gì cả. Sự phức tạp của việc tạo ra nỗ lực đã không gây ngạc nhiên; đã không có các tiến bộ toán học trong công việc. Việc tạo ra một số 512-bit mất khoảng như sức mạnh tính toán như mọi người đã tiên đoán. Nếu các khóa 512-bit là không an toàn ngày hôm nay, thì chúng từng chỉ là không an toàn vào tháng trước. Bất kỳ ai đang triển khai RSA nên phải chuyển sang các khóa 1024-bit vài năm trước, và nên nghĩ về các khóa 2048-bit từ hôm nay. Là mệt mỏi khi mọi người không nghe các nhà mật mã học khi họ nói rằng thứ gì đó là không an toàn, chờ đợi thay vì đối với ai đó thực sự thể hiện sự không an toàn đó.

Phân tích của RSA:

Bác bỏ của Certicom:

Các website nổi bật vẫn còn sử dụng RSA 512-bit:
  • Travelocity
  • Cửa hàng trực tuyến của Microsoft
  • Cửa hàng trực tuyến của Compaq
  • Cửa hàng trực tuyến của Godiva
  • Dr. Koop.com
  • Flowers N More
Có nhiều hơn nữa. Bạn có thể tự mình kiểm tra bằng việc kết nối tới một site với một phiên bản nội địa an toàn của Microsoft Internet Explorer 4.0.

Dịch: Lê Trung Nghĩa

Người đăng: vào lúc
Nhãn: ,

Không có nhận xét nào:

Đăng nhận xét

Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.

Đăng ký: Đăng Nhận xét (Atom)