1. Về bộ tạo giả ngẫu nhiên
Bộ tạo giả ngẫu nhiên đóng một vai trò hết sức quan trọng trong các ứng dụng mật mã, bởi vì chúng được sử dụng để tạo ra khoá cho các mã pháp đối xứng, các vecto khởi điểm cho một số chế độ của mã khối, các đại lượng dùng một lần (nonces), các mầm (seed) cho các giao thức trao đổi khoá... Thế nhưng, không đơn giản để có được một bộ tạo giả ngẫu nhiên thực sự. Trong phần này, chúng ta xem xét các tấn công lên bộ tạo số giả ngẫu nhiên đã được xây dựng trong hai hệ điều hành thông dụng là Windows và Linux.
Tấn công của Bleichenbacher lên bộ tạo khoá dùng một lần của DSA
Tûâ nùm 1998, Trung têm nghiïn cûáu mêåt maä ûáng duång (Centre for Applied Cryptographic Research -CACR) tại Đại học tổng hợp Waterloo đã đứng ra tổ chức Hội nghị về Mật mã học elliptic (Elliptic Curve Cryptography - ECC). Tại ECC’2001, Dan Bleichenbacher đã có báo cáo “Về việc sinh các khoá dùng một lần của DSA” [1]. Tại ECC’2002, Bleichenbacher đã được mời báo cáo lại kết quả này. Sau đây là tóm tắt của bài báo: 
“Tấn công này phân tích thuật toán chữ ký số DSA. Cho mỗi chữ ký một khoá ngẫu nhiên bí mật dùng một lần ki được sinh ra. Chuẩn đề xuất một phương pháp để sinh các khoá dùng một lần này, nó bị chệch. Tôi trình bày một tấn công khám phá khai thác độ chệch này. Khi đã cho đủ nhiều chữ ký thì có thể tìm được khoá bí mật nhanh hơn một cách đáng kể so với các thuật toán đã biết trước đây. Ví dụ, khoá bí mật có thể thường xuyên được tìm thấy khi cho 222 chữ ký trong thời gian 264 với bộ nhớ 240. Độ phức tạp của tấn công không phụ thuộc vào kích cỡ nhóm p”.
Phân tích bộ tạo số giả ngẫu nhiên của Linux
Ngày 6/3/2006, Zvi Gutterman, Benny Pinkas và Tzachy Reinman đã công bố bài báo “Phân tích bộ tạo số ngẫu nhiên Linux” [2]. Tóm tắt như sau:
“Linux là dự án mã nguồn mở quảng bá nhất. Bộ tạo số ngẫu nhiên Linux là một phần của nhân của tất cả các phiên bản Linux và dựa trên việc sinh ra tính ngẫu nhiên từ entropy của các sự kiện hệ điều hành. Đầu ra của bộ tạo này được sử dụng cho hầu hết mỗi giao thức an toàn, bao gồm việc sinh khoá TLS/SSL, chọn số tuần tự TCP, mã thư điện tử và mã hệ thống tệp. Mặc dù bộ tạo là một phần của dự án mã nguồn mở, nhưng mã nguồn của nó (khoảng 2.500 dòng lệnh) được viết rất kém và nó được vá bằng hàng trăm lệnh.
Chúng tôi đã sử dụng kỹ thuật dịch ngược tĩnh và động để nghiên cứu hoạt động của bộ tạo này. Bài báo này trình bày mô tả của thuật toán đó và mô tả một số tổn thương an toàn. Đặc biệt, chúng tôi chỉ ra một tấn công lên tính an toàn về phía trước của bộ tạo, nó cho phép kẻ thù địch, người mà biết trạng thái của bộ tạo, tính được các trạng thái và các đầu ra trước đó. Thêm vào đó, chúng tôi trình bày một vài lỗ hổng mật mã trong thiết kế của bộ tạo, cũng như các độ đo của entropy thực tế đã được nó thu thập lại và một phân tích quan trọng về cách sử dụng của bộ tạo trong các phiên bản Linux chạy trên các thiết bị không có đĩa cứng.
Thám mã Bộ tạo số giả ngẫu nhiên của Windows
Ngày 4/11/2007, các tác giả Leo Dorrendorf, Zvi Gutterman và Benny Pinkas đã công bố bài báo “Thám mã bộ tạo số ngẫu nhiên của Windows” [1]. Tóm tắt bài báo này nhû sau:
“Bộ tạo số giả ngẫu nhiên (PRNG) được sử dụng bởi hệ điều hành Windows là PRNG được sử dụng phổ biến nhất. Tính giả ngẫu nhiên của đầu ra của bộ tạo này là quan trọng đối với tính an toàn của phần lớn ứng dụng bất kỳ chạy trong Windows. Tuy vậy, thuật toán chính xác của nó chưa bao giờ được công bố.
Chúng tôi đã nghiên cứu mã nhị phân của một phiên bản Windows 2000, nó vẫn là hệ điều hành phổ dụng thứ hai (đứng sau Windows XP). Đầu tiên, chúng tôi đã kiến thiết lại thuật toán đã được sử dụng bởi bộ tạo số giả ngẫu nhiên (đó chính là hàm CryptGenRandom). Chúng tôi đã phân tích độ an toàn của thuật toán và tìm được một tấn công không tầm thường: khi đã cho trạng thái trong của bộ tạo, trạng thái trước đó có thể được tính trong O(223) phép toán (đó là tấn công lên độ an toàn về phía trước của bộ tạo, một tấn công có độ phức tạp O(1) lên độ an toàn về phía sau là tầm thường). Tấn công lên độ an toàn về phía trước minh chứng rằng bộ tạo là bị lỗi, vì từ lâu người ta đã biết cách để chống lại các tấn công như vậy.
Chúng tôi cũng phân tích cách mà bộ tạo chạy trong hệ điều hành và thấy rằng nó khuếch đại hiệu quả của các tấn công. Bộ tạo được chạy trong chế độ của người sử dụng thay cho chế độ nhân, vì thế dễ truy cập được trạng thái của nó thậm chí không cần các quyền ưu tiên của người quản trị. Các giá trị ban đầu trong một phần trạng thái của bộ tạo không được thiết lập một cách tường minh, mà thay vào đó chúng được định nghĩa bởi các giá trị tuỳ ý mà có mặt trên ngăn xếp (stack) khi bộ tạo được gọi tới. Hơn thế nữa, mỗi tiến trình chạy một bản sao khác của bộ tạo, và trạng thái của bộ tạo được làm tươi bằng entropy được hệ thống sinh ra chỉ sau khi sinh ra 128 Kbyte ở đầu ra cho mỗi tiến trình chạy nó. Kết quả của việc kết hợp quan sát này với tấn công của chúng ta là việc biết một trạng thái duy nhất có bộc lộ 128 Kbyte của đầu ra trong quá khứ và trong tương lai của bộ tạo.
Hệ quả của những phát hiện này là tấn công tràn bộ đệm hoặc một tấn công tương tự có thể được sử dụng để biết được một trạng thái duy nhất của bộ tạo. Sau đó, nó có thể được sử dụng để dự đoán tất cả các giá trị ngẫu nhiên, chẳng hạn như các khoá SSL, đã được sử dụng bởi tiến trình trong hoạt động quá khứ và tương lai. Tấn công này là trầm trọng hơn và hiệu quả hơn so với các tấn công đã biết khác, trong đó kẻ tấn công chỉ có thể biết được các khoá SSL nếu nó đang kiểm soát máy bị tấn công tại thời điểm các khoá đang được sử dụng”.
 Lỗi của bộ tạo ngẫu nhiên trong OpenSSL
Trên trang web của OpenSSL, mục Tư vấn an toàn OpenSSL (OpenSSL Security Advisory ) ngày 29/11/2007 có bản tin “OpenSSL FIPS Object Module Vulnerabilities” với nội dung như sau
“Một lỗ hổng đáng kể trong cài đặt PRNG cho OpenSSL FIPS Object Module v1.1.1 đã được công bố bởi Geoff Lowe từ Secure Computing Corporation.  Do lỗi lập trình trong tự kiểm tra FIPS, việc tự động nạp lại mầm không bao giờ xảy ra. Điều này có nghĩa là khoá và mầm của PRNG được sử dụng tương ứng với lần tự kiểm tra cuối cùng. FIPS PRNG nhận dữ liệu mầm bổ sung chỉ từ thông tin ngày - giờ, nên dữ liệu ngẫu nhiên được sinh ra là dự đoán được khá nhiều so với nó cần phải là không dự đoán được, đặc biệt là đối với một số lần gọi đầu tiên. Lỗi này được theo dõi như là CVE-2007-5502”.
2. Về phần mềm PGP
Trong luận văn thạc sĩ của mình được hoàn thành từ năm 2001 [10],  Sieuwert van Otterloo đã trình bày về 5 lỗi đối với các phiên bản khác nhau của PGP như sau:
- Lỗi về cách lấy ngẫu nhiên trong Linux: Phiên bản PGP 5.0i cho Linux đã mắc phải một lỗi nghiêm trọng, nó làm cho các khoá được tạo ra là dễ đoán được. Thay cho lệnh RandBuf = read(fd, &RandBuf, count) phải là lệnh read(fd, &RandBuf, count). Vấn đề này đã được phát hiện bởi Germano Caronni vào ngày 23/5/2000.

- Lược đồ khoá cho PGPdisk: PGPdisk là một chương trình cho phép mã cả ổ đĩa cứng. Đây là lỗi trong lược đồ khoá cho CAST ở trong một số phiên bản của PGPdisk. Các phiên bản bị lỗi là PGPdisk cho Windows 1.0 và PGPdisk mà được phát hành cùng với PGP 6.0.1. Đến phiên bản mà đi cùng với PGP 6.0.2 thì lỗi này được sửa. Lỗi này được tìm ra bởi Network Associates Incorporated.

Lỗi ADK: Tháng 8/2000, Ralph Senderek, một nhà nghiên cứu người Đức đã phát hiện ra một lỗi liên quan tới Additional Decryption Keys. Các phiên bản
từ 5.5.x tới 6.5.3 bị mắc lỗi này [10]
- Tấn công khóa bí mật Tiệp Ngày 20/3/2001, Vlastimi Klima và Tomas Rosa, hai nhà khoa học Tiệp đã công bố một tấn công mới lên OpenPGP và PGP, tấn công này có mục tiêu là tìm ra khoá bí mật của cặp khoá bí mật/công khai
- Lỗi áo giáp ASCII (ASCII armor bug): Lỗi này đã được phát hiện vào tháng 4/2001 bởi Chris Anley thuộc công ty bảo mật Atstake. Lỗi này như sau: việc mở một file được bọc áo giáp ASCII chẳng hạn như khoá công khai hay chữ ký được đính kèm có thể gây nên việc tạo ra một file tuỳ ý trên máy đích. Trên nền tảng Windows, điều này có thể dẫn tới việc thực hiện mã lệnh bất kỳ trên máy đích.
Đến tháng 6/2001 chính Sieuwert van Otterloo đã phát hiện ra lỗi Tấn công nhiều ID người sử dụng dựa trên nhầm lẫn được tạo ra bởi các khoá mà có nhiều ID người sử dụng.
Năm 2003, Kahil Jallad, Jonathan Katz vaâ Bruce Schneier đã viết bài “Cài đặt các tấn công bản mã lựa chọn chống lại PGP và GnuPG” [6]. Tóm tắt của bài báo đó như sau:
“PGP và các giao thức bảo mật thư tín điện tử khác, về lý thuyết, bị tổn thương mức cao bởi các tấn công bản mã lựa chọn, trong đó người nhận thư điện tử hành động như “tiên đoán giải mã” không có ý thức [7]. Các tấn công như vậy là hoàn toàn có khả năng xảy ra. Ở đây, chúng tôi khảo sát các khẳng định này một cách chi tiết hơn qua việc cài đặt các tấn công đã được đề xuất. Một mặt, chúng ta có thể cài đặt thành công các tấn công đã được mô tả chống lại PGP và GnuPG (hai gói phần mềm được sử dụng rộng rãi) trong một số các thiết lập khác nhau, mặt khác chúng ta có thể chỉ ra rằng các tấn công phần lớn sẽ bị thất bại khi dữ liệu bị nén trước khi mã.
Các tấn công không thành công vì rất nhiều nguyên nhân tình cờ; tính kháng lại các tấn công này dường như không do nỗ lực có ý thức bất kỳ được làm để ngăn chặn chúng. Dựa trên các kết quả của mình, chúng tôi cũng khuyến cáo các thay đổi trong chuẩn OpenPGP để làm giảm tính hiệu quả của các tấn công đã được nói tới trong các thiết đặt naây” [8]. 
Trong hội nghị Eurocrypt năm 2004, Phong Q. Nguyen có báo cáo “Chúng ta có thể tin cậy phần mềm mật mã? Các lỗ hổng mật mã trong GNU Privacy Guard v1.2.3” [5]. Sau đây là tóm tắt của bài báo đó:
“Ngày càng nhiều phần mềm sử dụng mật mã. Nhưng bằng cách nào mà người ta có thể biết được rằng cái đã được cài đặt là mật mã tốt. Đối với một phần mềm có bản quyền người ta không thể nói gì nhiều trừ khi người ta tiến hành việc dịch ngược (reverse-engineering), và lịch sử có thiên hướng chỉ ra rằng ở đây thường gặp một mật mã tồi hơn là một mật mã tốt. Trong bài báo này, chúng tôi minh hoạ quan điểm này bằng cách kiểm tra trường hợp của một ứng dụng Internet cơ sở về mật mã: bảo mật thư tín. Chúng tôi phân tích một phần của mã nguồn của phiên bản cuối cùng của GNU Privacy Guard (GnuPG or GPG), một thay thế nguồn mở tự do cho phần mềm PGP nổi tiếng, nó tương thích với chuẩn OpenPGP, và được đưa vào trong phần lớn các phân phối GNU/Linux như Debian, MandrakeSoft, Red Hat và SuSE. Chúng tôi quan sát thấy một số các lỗ hổng mật mã trong PGP v1.2.3. Lỗ hổng nghiêm trọng nhất đã được tìm thấy trong PGP gần 4 năm trước: chúng tôi chỉ ra rằng một khi một chữ ký ElGamal của một thông điệp tuỳ ý đã được phát hành (được tạo bởi GPG), người ta có thể khôi phục khoá bí mật của người ký trong thời gian ít hơn 1 giây trên máy PC. Như một hệ quả, các chữ ký ElGamal và các khoá được gọi là ElGamal ký + mã gần đây được loại bỏ khỏi PGP.
3. Thư viện mật mã
Đầu năm 2008, các tác giả Daniel Mall và Qing Zhong đã công bố bài báo “Mã nguồn mở là chưa đủ, tấn công gói phần mềm EC của BouncyCaste phiên bản 1.x 132” [9]. Sau đây là tóm tắt của bài báo đó.
“BouncyCastle cung cấp mật mã mã nguồn mở bằng Java, nó cung cấp các lớp cho mật mã đường cong elliptic. Chúng tôi tìm thấy lỗ hổng trong lớp ECPoint là kết quả tương tác không thích hợp của các thuật toán sơ cấp. Chúng tôi chỉ ra cách khai thác lỗ hổng này thành một tấn công thế giới thực, ví dụ, trên lược đồ mã hoá ECIES. BouncyCastle đã sửa lỗi này (phiên bản 1.x_133 hoặc cao hơn) nhưng tất cả các phiên bản cũ hơn vẫn bị tổn thương nhiều đối với kẻ tấn công tích cực và tấn công chỉ ra một tổn thương nào chắc chắn của các thuật toán phê chuẩn có liên quan”.
4. Một số lưu ý khi sử dụng mã nguồn mở
Qua việc xem xét các bài báo đã nêu ở trên, chúng tôi nhận thấy rằng: Việc lợi dụng một số phần mềm mật mã có mã nguồn mở để nghiên cứu xây dựng các ứng dụng mật mã là rất cần thiết, trong nhiều trường hợp nó sẽ giúp cho ta có được giải pháp can thiệp mật mã, nhưng cần lưu ý:
- Đối với giải pháp can thiệp mật mã cần kiểm soát mã nguồn, mô tả lại được lưu đồ hoạt động để tránh có kênh ngầm hoặc những lỗ hổng an toàn

- Đối với đoạn mã lệnh mật mã: cần thay đổi bằng những đoạn mã lệnh do mình lập ra theo những thuật toán/giao thức đã được đánh giá là an toàn, tốt nhất là những thuật toán/giao thức thuộc dạng an toàn chứng minh được.