Ứng dụng công nghệ tính toán đa dụng trên các bộ xử lý đồ họa trong bài toán khôi phục mật khẩu tệp nén zip

GIỚI THIỆU CHUNG

Tổng quan về mật mã học

Mật mã học (tiếng Anh là Cryptography hoặc Cryptology) là ngành khoa học nghiên cứu về các kỹ thuật toán học liên quan tới các khía cạnh an toàn thông tin. Trước thời kỳ hiện đại, mật mã học chỉ tập trung duy nhất tới tính bí mật của bản tin – tức là gắn liền với sự mã hóa, đó là quá trình chuyển đổi các thông tin thông thường (bản rõ) ở dạng có thể nhận thức được thành một dạng không thể nhận thức được, làm cho thông tin không thể đọc được nếu như không có các kiến thức bí mật (được gọi là khóa dùng để giải mã cho bản tin đó) Việc mã hóa được dùng để đảm bảo tính bí mật của thông tin trong lưu trữ cũng như trong thông tin liên lạc, chẳng hạn trong công tác tình báo, quân sự, ngoại giao hay là kinh tế, thương mại Trong những thập niên gần đây, lĩnh vực này đã được mở rộng vượt ra ngoài các mối quan tâm về tính bí mật và bao gồm các kỹ thuật khác như kiểm tra tính toàn vẹn của thông điệp, xác thực định danh người gửi/nhận, chữ ký số, chứng thực khóa công khai.

Về mặt thuật ngữ, cho đến thời kỳ hiện đại, thuật ngữ cryptography được dùng để nhắc đến việc sử dụng và thực hành các kỹ thuật mật mã hóa Nhiều người sử dụng thuật ngữ cryptography và cryptology hoán đổi cho nhau trong tiếng Anh Tuy vậy, theo các chuyên gia về mật mã cryptology dùng để chỉ sự nghiên cứu kết hợp của mật mã hóa (cryptography) và thám mã (cryptanalysis).

Thám mã (tiếng Anh là Cryptanalysis) – là khoa học nghiên cứu về các phương pháp lấy lại ý nghĩa của các thông tin đã bị mã hóa, mà không cần truy xuất tới các thông tin bí mật mà thường là cần phải có để có thể làm được điều đó Thông thường, điều này liên quan đến hiểu biết về cách hệ thống làm việc và tìm ra một khóa bí mật Mục tiêu của thám mã (phá mã) là tìm những điểm yếu hoặc không an toàn trong phương thức mật mã hóa Thám mã có thể được thực hiện bởi những kẻ tấn công mục đích xấu, nhằm làm hỏng hệ thống; hoặc bởi những người thiết kế ra hệ thống (hoặc những người khác) với ý định đánh giá độ an toàn của hệ thống.Khoa học thám mã luôn đi cùng với khoa học mật mã trong suốt chiều dài lịch sử của mật mã học – một thuật toán mã hóa mới được thiết kế để thay thế những thiết an ninh thông tin: sự phát triển của một nhánh luôn thúc đẩy sự phát triển của nhánh kia và ngược lại.

Trong lịch sử phát triển, sự phát triển vượt trước của một nhánh so với nhánh còn lại đôi khi mang đến những lợi ích to lớn cho đời sống, thậm chí còn quyết định vận mệnh của cả một đất nước.Ví dụ như sự thành công trong việc thám mãZimmermann Telegram trong thế chiến thứ nhất đã kéo Hoa Kỳ vào cuộc chiến, hay việc thám mã thành công hệ mã German được đánh giá góp phần rút ngắn thế chiến thứ hai đi vài tháng [4].

Giới thiệu bài toán thám mã tệp nén ZIP và đề xuất giải pháp

Nguyên thủy, các phương pháp nén như PKZip, Deflate, LZMA được sử dụng nhằm giảm thiểu kích thước dữ liệu, từ đó giúp cho việc lưu trữ cũng như trao đổi chúng được hiệu quả.

Do việc bảo mật thông tin thường luôn đi kèm với các kỹ thuật lưu trữ và trao đổi thông tin nên bên cạnh các giải thuật nén hiệu quả, những công cụ nén phổ biến như WinZip hay WinRar thường tích hợp khả năng mã hoá thông tin nén, thông thường là sử dụng những hệ mã đối xứng phổ biến như DES hay AES. Để thuận tiện cho người dùng, khoá bí mật cho các hệ mã này được sinh ra từ một mật khẩu do người gửi nhập vào thông qua một hàm băm và được sử dụng để mã hoá tài liệu Sau đó mật khẩu được người gửi chuyển đến cho người nhận qua một kênh an toàn và được người nhận sử dụng để sinh khoá cho quá trình giải mã Quá trình mã hoá và giải mã tệp nén Zip được mô tả như trong hình 1-1.

Hình 1-1 Mã hóa, giải mã tệp nén Zip

Bài toán thám mã tệp nén Zip được đặt ra ở đây là: cho một tệp nén Zip được bảo vệ bởi mật khẩu, hãy xác định nội dung tài liệu trong đó mà không cần sử dụng mật khẩu này.

Trong thực tế, với các hệ mã yếu như RC4 hay DES, việc thám mã có thể được tiến hành thông qua phương pháp tấn công vét cạn trên không gian khoá trong thời gian chấp nhận được Các kết quả [3],[5] là những minh chứng cho kỹ thuật này.

Với các hệ mã mạnh như AES (hệ mã được sử dụng phổ biến trong các phiên bản mới của WinZip) việc tấn công vét cạn như vậy là không khả thi AES[1], tiêu chuẩn mã hóa tiên tiến, là một thuật toán mã hóa khối AES làm việc với các khối dữ kiệu 128 bít (4x4 bytes) và khóa của nó có độ dài là 128, 192 hoặc 256 bít AES có thể dễ dàng thực hiện với tốc độ cao bằng phần mềm hoặc phần cứng và không đòi hỏi nhiều bộ nhớ Là một hệ thống mã hóa mạnh, AES-128/AES-256 với kích thước khóa là 128/256 bít có đến 2 128 /2 256 khả năng phải thử để có thể tìm ra được mật khẩu ban đầu Một số nghiên cứu gần đây như giải thuật XSL[2] cho phép giảm không gian khóa từ 2 128 khả năng xuống còn khoảng 2 100 khả năng Tuy nhiên, ngay cả như vậy, việc thử hết tất cả các khả năng đó vẫn là không chấp nhận được đối với các hệ thống tính toán thông dụng.

Cách tiếp cận được đề xuất ở đây là không trực tiếp tấn công trên không gian khoá AES Thay vào đó, do khoá cho các hệ mã của tệp nén Zip được sinh ra từ mật khẩu người dùng thông qua một hàm băm được công bố trong đặc tả tệp nén[8] Không gian mật khẩu mặc dù lớn nhưng tính khả thi cho việc thám mã tệp nén dựa trên không gian mật khẩu cao hơn nhiều so với thám mã dựa trên không gian khoá. Ngoài ra, khi nén một tệp tin gốc, nếu chúng ta lựa chọn phương pháp nén mặc định, thì giải thuật được lựa chọn nén là Deflate Mọi thông tin liên quan đến giải thuật nén và mã hóa nào được lựa chọn, có thể lấy được nhờ thông tin trực tiếp lưu trong header của tệp nén ZIP Đối tượng nghiên cứu cụ thể trong đồ án này là tệp tin nén zip được nén bằng giải thuật DeFlate, và mã hóa bằng giải thuật AES -128 hoặc AES-256 Thông tin này là quan trọng cho việc khôi phục chính xác mật khẩu đúng cho tệp nén đã được bảo vệ nhờ quy trình giải mã và giải nén tệp tin.

Trở ngại lớn nhất cho phương pháp thám mã dựa trên không gian mật khẩu này là độ phức tạp tính toán của hàm băm nói trên khá cao, cộng thêm với kỹ thuật salting nhằm chống tấn công tính toán trước của tệp nén Zip khiến cho việc tấn công vét cạn trở nên rất kém hiệu quả trên các hệ thống tính toán thông dụng. Để vượt qua các khó khăn này, trước hết, ứng dụng công nghệ tính toán song song trên các bộ xử lý đồ hoạ đa lõi GPU[7] trong việc thực hiện hàm băm phức tạp nói trên để kiểm tra đồng thời các mật khẩu từ không gian tìm kiếm mật khẩu và sinh khoá AES cho các mật khẩu có thể đúng Sau đó, áp dụng kỹ thuật nhận dạng bản

Nhiệm vụ của đồ án

Xuất phát từ cùng một quan điểm về tầm quan trọng của thám mã, mục tiêu của đồ án này là nghiên cứu phương pháp thám mã cho đối tượng là các tệp nén Zip được bảo vệ bởi mật khẩu.

Phạm vi của đồ án: Đồ án tập trung vào đối tượng nghiên cứu là các tệp nén ZIP được tạo ra bởi công cụ ZIP cụ thể là phần mềm Winzip phiên bản từ 9.0 trở đi. Winzip đáp ứng các yêu cầu về độ khó cho bài toán bởi nó hỗ trợ phương thức mã hóa mạnh là AES-128/256, ngoài ra, phương thức nén phổ biến nhất là DEFLATE được lựa chọn

Nội dung của đồ án gồm có 2 phần chính:

 Phần thứ nhất giới thiệu phương pháp kiểm tra một mật khẩu cho trước có khả năng là mật khẩu đúng hay không, từ đó ứng dụng sức mạnh tính toán của các bộ xử lý đồ họa đa lõi trong việc sinh khóa và kiểm tra sơ bộ mật khẩu của tệp nén, kết quả là hình thành nên một không gian mật khẩu có thể đúng (cũng bao gồm khóa AES) nhỏ hơn rất nhều so với không gian mật khẩu ban đầu.

 Phần thứ hai đưa ra phương pháp xác định mật khẩu đúng cho tệp nén ZIP, việc này liên quan đến phân tích phương thức nén và mã hóa được sử dụng cho tệp nén của công cụ ZIP như WINZIP, và kỹ thuật nhận dạng bản rõ

Từ đó, cấu trúc của đồ án gồm các phần như sau

- Chương 2: Trình bày các nền tảng cơ sở để giải quyết bài toán, cách thức sinh khóa AES từ mật khẩu người dùng cung cấp, và hai phương pháp nén và mã hóa của Winzip đã được lựa chọn, chương này cũng trình bày cách thức giải mã và giải nén một tệp ZIP.

- Chương 3: Giới thiệu công nghệ tính toán song song đa dụng trên các bộ xử lý đồ họa GPU.

- Chương 4: Đưa ra chiến lược để giải quyết bài toán, ý tưởng của việc xây dựng chương trình song song trên các GPU.

- Chương 5: Trình bày các kết quả thử nghiệm, so sánh tốc độ sinh khóa và tốc độ khôi phục mật khẩu giữa hai chương trình tuần tự (trên CPU) và song song (trên các GPU)

- Chương 6: Kết luận và đề xuất hướng phát triển cho đề tài.

Tổng kết

Chương 1 đưa ra một bức tranh tổng quan về các vấn đề nghiên cứu, nhiệm vụ, nội dung của đồ án, theo đó đồ án thực hiện thám mã một tệp nén ZIP mà quy trình của nó có thể được chia thành hai pha chính:

– Pha 1 Xác định tập mật khẩu ứng cử Pha này dựa trên 1 giá trị kiểm tra mật khẩu được lưu trong tệp nén ZIP để sinh ra một tập mật khẩu ứng cử bé hơn từ một không gian mật khẩu cho trước.

– Pha 2 Kiểm tra từng mật khẩu ứng cử bằng kỹ thuật nhận dạng bản rõ để xác định mật khẩu đúng.

Các chương tiếp theo mô tả cách thức thực hiện các pha này.

SƠ LƯỢC VỀ NÉN VÀ MÃ HÓA TRONG TỆP ZIP

Thông tin mã hóa AES trong tệp nén ZIP

Về cơ bản, định dạng của tệp ZIP được giữ nguyên như trình bày ở phụ lục A, sự khác biệt là các file được mã hóa bởi AES sử dụng một trường “extral data” mới, một mã mới cho phương thức nén, và một giá trị trong trường CRC phụ thuộc vào phiên bản mã hóa (AE-128/256) Ở đây ta quan tâm đến việc đọc ra thông tin về phương thức nén và nội dung của trường “extral data”. a Phương thức nén và cờ mã hóa

Cũng như mọi file bị mã hóa khác, bit 0 của trường “general purpose bit flags” phải được thiết lập lên 1 trong bản ghi local file header và central directory của mỗi file mã hóa bằng AES.

Thêm nữa, biểu hiện của một file mã hóa bằng AES trong một tệp ZIP được chỉ ra bởi từ mã mới của phương thức nén = 99 trong các bản ghi local file header và central directory, còn mã thực sự cho phương thức nén sẽ được lưu trong trường extral field b AES extra data field

Một file mã hóa bởi AES sẽ có một trường “extra field” đi cùng với nó Trường này được lưu trong cả hai bản ghi local file header và central directory của file đó.ID header của extra data cho mã hóa AES là 0x9901 Trường extra field hiện tại có độ dài 11: 7 byte dữ liệu + 2 byte cho ID header và 2 byte cho kích thước dữ liệu Do đó, trường extra data chiếm tổng cộng 22 byte cho mỗi file trong file ZIP (11 byte trong central header và 11 byte trong local header)

Offset Size(bytes) Nội dung

2 2 Kích thước dữ liệu (hiện tại = 7)

4 2 Số hiệu phiên bản của nhà sản xuất

6 2 ID nhà sản xuất - 2 ký tự

8 1 Giá trị nguyên chỉ ra độ mạnh của AES

9 2 Phương thức nén thực sự được dùng

Bảng 2-1 Cấu trúc tường extra Ý nghĩa:

 Data size: giá trị hiện tại là 7, nhưng bởi vì đặc tả này có thể sẽ được chỉnh sửa trong tương lai để lưu thêm dữ liệu trong trường extra.

 ID nhà sản suất: trường này luôn được thiết lập 2 ký tự ASCII “AE”

 Phiên bản nhà sản xuất: phiên bản nhà sản xuất cho AE-1 là 0x0001. Phiên bản nhà sản xuất cho AE-2 là 0x0002

 Độ mạnh mã hóa: Các giá trị sau thể hiện chế độ (độ mạnh mã hóa) cho AE-1 và AE-2 là

Value Strength 0x01 128-bit encryption key 0x02 192-bit encryption key 0x03 256-bit encryption key Đặc tả mã hóa [1] chỉ hỗ trợ các khóa mã hóa 128,192, và 256 bit. Tuy nhiên, phiên bản hiện tại của WINZIP không hỗ trợ mã hóa các file sử dụng độ dài khóa 192 bit.

 Phương thức nén: là phương thức nén thực sự được sử dụng, điều này là cần thiết bởi vì nếu một tập tin được mã hóa AES thì các phương thức nén lưu ở local header và central header đều là 99 c Định dạng dữ liệu mã hóa

Dữ liệu mã hóa AES được lưu cùng với một số thông tin bổ sung như sau

Lúc này, giá trị trong các trường “compressed size” của các bản ghi local file header và centra directory entry là tổng kích thước của tất cả các thành phần trên Đó là tổng kích thước của Salt, Pvv, dữ liệu mã hóa, và AC.

Salt là một chuỗi byte ngẫu nhiên hoặc giả ngẫu nhiên mà sẽ được kết hợp với mật khẩu mã hóa để tạo ra các khóa mã hóa và xác thực Giá trị salt được sinh ra bởi ứng dụng mã hóa và được lưu dưới dạng không mã hóa cùng với dữ liệu file Việc thêm các giá trị salt tới các mật khẩu đem lại một số lợi ích về bảo mật và làm cho các tấn công từ điển dựa trên các khóa được tính toán khẩu và salt, chúng có thể làm rò rỉ thông tin lẫn nhau Ví dụ, nếu có thể xác định liệu hai file có được mã hóa với cùng mật khẩu và salt hay không, một kẻ tấn công đã thực sự biết nội dung của một trong hai file đó có thể xác định một phần hoặc toàn bộ nội dung của file còn lại.

Kích thước của giá trị Salt phụ thuộc vào độ dài của khóa mã hóa, như sau:

 Giá trị kiểm tra mật khẩu PVV

Giá trị hai byte này được sinh ra như là một phần đầu ra của quá trình sinh khóa mã hóa (hoặc giải mã) Khi mã hóa, một giá trị kiểm tra được sinh ra từ mật khẩu mã hóa và được lưu cùng với file mã hóa Trước khi giải mã, một giá trị kiểm tracos thể được sinh ra từ mật khẩu giải mã và được so sánh với giá trị được lưu cùng với file, nhằm mục đích kiểm tra nhanh hầu để phát hiện hầu hết (nhưng không phải toàn bộ) các mật khẩu không đúng Giá trị này được lưu mà không mã hóa.

 Dữ liệu mã hóa Đây là toàn bộ dữ liệu gốc sau khi mã hóa, được Winzip thực hiện sau khi nén, phương thức mã hóa được sử dụng là giải thuật AES trong chế độ đếm

 Mã xác thực thông điệp(authentication code)

Giá trị 10 byte này cung cấp một kiểm tra với chất lượng rất cao rằng nội dung của file mã hóa không bị thay đổi trong lúc truyền hay lưu trữ Giá trị này được sinh ra trong quá trình mã hóa, nhờ thực hiện hàm băm Hmac-sha1 lên từng khối dữ liệu, và được lưu dưới dạng không bị mã hóa.

Hàm băm sinh khóa và cách kiểm tra một mật khẩu ứng cử

Như mô tả ở hình 1-1 Ở bước mã hóa, khi người dùng nhập mật khẩu vào để bảo vệ tệp nén Zip, hệ thống WINZIP sẽ sử dụng một giải thuật tên là PBKDF2 để sinh khóa mã hóa, giải thuật này được đặc tả chi tiết trong RFC 2898[16] Ban đầu nó sẽ sinh ra một giá trị ngẫu nhiên salt, giá trị này có độ dài tương ứng là 8, 12, hoặc 16 byte tùy theo lựa chọn của người dùng khi mã hóa là AES-128 bit/ AES-192 bit hoặc AES-256 bit Giá trị salt và độ dài khóa dkLen được lưu trong dữ liệu tệp nén zip dưới dạng dữ liệu bản rõ (dữ liệu này không được mã hóa) Khóa mã hóa được sinh một lần bởi hàm băm một chiều, sử dụng ngay tại thời điểm mã hóa và sau đó hủy không lưu Ngoài salt và dkLen, nó còn lưu giá trị kiểm tra mật khẩu PVV và mã xác thực (10byte) – Authentication Code

Giá trị salt được sử dụng để trộn với mật khẩu đúng của tệp tin nén, dùng để chống tấn công tính toán trước, giúp tăng tính bảo mật.

Salt và dkLen được lưu lại trong tệp tin zip, giúp hệ thống WINZIP sinh lại khóa từ mật khẩu người dùng nhập vào khi cần xem nội dung của tệp tin đã được bảo vệ. Muốn sinh lại khóa từ mật khẩu, ta chỉ cần gọi lại giải thuật PBKDF2 để điều chế khóa, với đầu vào là salt, dkLen và mật khẩu thử

Giá trị PVV cho phép loại bỏ những mật khẩu thử mà chắc chắn không phải là mật khẩu đúng của tệp nén zip, bằng cách này giúp cho hệ thống winzip không phải thực hiện quá trình giải mã, giải nén tốn kém chi phí Tuy nhiên điều này lại là điểm yếu đối với tấn công lên không gian mật khẩu với hệ thống tín toán mạnh chẳng hạn như tính toán trên các bộ xử lý đồ họa GPU.

Giá trị Authentication Code giúp phát hiện chính xác mật khẩu người dùng Với mỗi mật khẩu thử cho giá trị PVV trùng khớp với giá trị PVV lưu trong tệp nén zip,khóa sinh ra dùng thực hiện quá trình giải mã, giải nén và cho ra là giá trịAuthentication Code Nếu giá trị này trùng với Authentication Code lưu trong tệp nén Zip thì nó là mật khẩu đúng Ngoài ra, giá trị AC cũng giúp phát hiện dữ liệu tệp nén zip khi trao chuyển qua đường mạng có bị thay đổi nội dung hay không.Nếu bị thay đổi, giá trị AC này không còn trùng với giá trị AC lưu trong tệp zip.Như vậy, ta sử dụng PBKDF2 để xác thực một mật khẩu thử có phải là mật khẩu ứng cử hay không Giải thuật được mô phỏng như sau

Hình 2-2 Giải thuật kiểm tra một mật khẩu có phải là ứng cử

Các bước chi tiết thực hiện giải thuật

Nếu dkLen > (2 32 – 1)*hLen, đầu ra “độ dài khóa quá lớn” và dừng chương trình Đặt l là số khối hLen ở khóa được sinh ra, r là phần dư của khối l = CEIL(dkLen / hLen), r = dkLen – (l -1)*hLen Ở đây, kí hiệu CEIL(x) là hàm làm tròn, là số nguyên lớn nhất còn nhỏ hơn hoặc bằng x

Với mỗi khối như vậy, gọi thực hiện hàm băm HMAC-SHA1 một nghìn lần, cho đầu ra là các T_k, k chạy từ 1 đến l.

Ghép T_1 đến T_l, rồi lấy hai byte ở vị trí dkLen*2 và dkLen*2 + 1 làm giá trị TestPVV, các byte từ vị trí 0 đến dkLen -1 làm khóa mã hóa.

Giá trị TestPVV được đem so sánh với giá trị PVV lưu trong tệp nén zip, nếu trùng khớp chứng tỏ mật khẩu thử có khả năng là mật khẩu đúng Tập các mật khẩu như vậy được gọi là tập mật khẩu ứng cử.

Phương thức nén và giải nén

WINZIP tích hợp nhiều phương thức nén khác nhau, tuy nhiên phương thức DEFLATE là thông dụng nhất và được lựa chọn làm phương thức nén mặc định khi nén tài liệu Deflate[12] là một định dạng nén không mất mát dữ liệu và là kết hợp của giải thuật LZ77 và mã Huffman

Trước hết dữ liệu được nén sử dụng giải thuật LZ77, sau đó sẽ được mã hóa sử dụng mã Huffman Phần tiếp theo trình bày tóm lược giải thuật LZ77 và mã Huffman và cách chúng được sử dụng trong định dạng Deflate. a Giải thuật LZ77

Nguyên lý của các phương pháp từ điển về nén dữ liệu là : nén nhiều xâu có thể đạt hiệu năng hơn so với nén từng ký hiệu đơn (ví dụ mã hóa Huffman) Trong phương pháp này, các xâu được thêm vào một từ điển, và các xuất hiện sau đó sẽ được tham chiếu qua từ điển Do đó để biểu diễn cho các xâu trùng lặp chỉ cần dùng một con trỏ, việc làm này sẽ giảm bộ nhớ cần lưu trữ cho dữ liệu đầu vào

Giải thuật LZ77 là phương pháp nén dữ liệu sử dụng một từ điển được xây dựng vào lúc chạy, nhìn dữ liệu qua một cửa sổ dịch có kích thước cố định, phần dữ liệu bên ngoài cửa sổ không được tham chiếu hoặc đã mã hóa Càng nhiều dữ liệu được mã hóa, cửa sổ càng dịch đi nhiều cũng có nghĩa loại bỏ dữ liệu đã mã hóa cũ nhất từ khung nhìn và thêm dữ liệu chưa mã hóa vào đó Cửa sổ dịch được chia thành hai phần search buffer chứa dữ liệu đã được xử lý, và lookahead buffer chứa dữ liệu vẫn chưa được mã hóa (search buffer được xem là từ điển).

Mã giả của giải thuật:

Con trỏ tham chiếu tới xâu lặp có dạng (postion, length) , và từ mã đầu ra sẽ có dạng (postion, length, ký hiệu tiếp theo không đối sánh)

Ví dụ: nén xâu S sau đây sử dụng LZ77 :

Ls =9 (length of look-ahead buffer) n (window size)

Một số tính toán ban đầu cho chiều dài từ mã : Lc = logα(n − Ls)+ logα(Ls)+1 Trong ví dụ này ta có: (α =3 là số ký tự của bộ ký tự {0,1,2})

Ban đầu search buffer được nạp các số 0 và lookahead buffer được nạp với 9 ký tự đầu tiên của S Giải thuật tìm kiếm đối sánh dài nhất trong search buffer Bởi vì nó được lấp đầy với các số 0, nên mọi xâu con có độ dài 2 đều có thể sử dụng được Tuy thế ta sử dụng xâu con bắt đầu từ vị trí cuối cùng trong search buffer là 8 (nếu đếm từ 0), bởi vì một đặc tính của LZ77 là đối sánh có thể được mở rộng sang cả lookahead buffer!

Hình 2-2 thể hiện một ví dụ minh họa cho giải thuật nén

Hình 2-3 Ví dụ nén dữ liệu sử dụng giải thuật LZ77. Đối sánh đầu tiên được mã hóa thành từ mã C1" 02 1 22 là vị trí bắt đầu của đối sánh trong search buffer biểu diễn dưới hệ cơ số 3(810 "3) , 02 là chiều dài của đối sánh và 1 là ký tự tiếp theo không sánh Sau đó cửa sổ được dịch đi length + 1 vị trí tức là 3 vị trí, và sẽ tiếp tục tìm xâu đối sánh, ở đây đối sánh tiếp theo được mã hóa thành C2 = 21 11 2 Cứ như thế cho đến hết stream đầu vào.

Giải mã : Một bộ giải mã cũng bắt đầu với một search buffer được điền đầy bởi 0 và đảo ngược lại quá trình mã hóa.

Nếu một đối sánh được mở rộng sang lookahead buffer, bộ giải mã đơn giản bắt đầu giải mã và sau đó tìm phần còn lại của đối sánh đó trong phần thực sự đã giải mã của từ mã (ví dụ như lúc giải mã từ mã C2)

Hình 2-4 Ví dụ giải nén dữ liệu sử dụng giải thuật LZ77 b Mã Huffman

Các mã Huffman được dùng cho mỗi bộ ký tự trong định dạng DEFLATE có hai thêm luật bổ sung :

- Tất cả các mã của một độ dài bit cho trước có các giá trị liên tiếp theo thứ tự từ điển, theo cùng thứ tự như các ký tự xuất hiện

- Các mã ngắn hơn đi trước các mã dài hơn theo thứ tự từ điển

Ta gọi loại mã này là mã canonical Huffman

Ví dụ mã Huffman cho bộ alphabet sau thỏa mãn điều đó

Tức là, 0 đi trước 10 , 10 đi trước 11x, và 110 và 111 là liên tiếp theo thứ tự từ điển

Cho luật như trên, ta có thể xác định mã Huffman cho một bộ ký tự chỉ cần đưa ra các độ dài bit của các mã cho mỗi ký tự theo thứ tự của bộ ký tự; như thế là đủ để xác định các mã đúng Trong ví dụ này, mã Huffman hoàn toàn xác định bằng thứ tự liên tiếp các độ dài bit (2,1,3,3)

Giải thuật sau sinh ra các mã như là các số nguyên, nhằm để đọc từ bit có trọng số cao nhất đến bit có trọng số thấp nhất Các chiều dài mã được khởi tạo trong tree[I].Len; các mã được sinh ra trong tree[I].Code

 Tính toán số lượng mã cho mỗi chiều dài mã Gọi bl_count[N] là số mã của độ dài N, N>=1

 Tìm giá trị bằng số của mã nhỏ nhất cho mỗi chiều dài mã : code = 0; bl_count[0]=0; for (bits = 1; bits β, với α là một biến đơn và β là một chuỗi các biến và các kết thúc. Hình 4-4 đưa ra một ví dụ của một văn phạm cùng với xác suất xuất hiện của các luật.

 Các cấu trúc pre-terminal được sinh ra theo thứ tự xác suất giảm dần bằng các bước xây dựng cây như sau: o Đặt S là gốc của cây o Các con của gốc là các pre-terminal với xác suất cao nhất được sinh ra từ các cấu trúc dạng base bằng cách thay thế tất cả các xuất hiện S và D bằng các ký tự và các chữ số tương ứng như được thể hiện trong văn phạm o Tiếp tục sinh cây bằng cách thay thế một ký tự hoặc một chữ số có xác suất cao trong một pre-terminal bằng ký tự hoặc chữ số có xác suất thấp hơn o Hình 4-5 thế hiện một ví dụ sinh cây để tìm các pre-terminal theo thứ tự giảm dần của xác suất xuất hiện.

 Một mật khẩu được sinh ra từ một cấu trúc pre-terminal bằng cách thay thế L ký tự trong cấu trúc bằng một từ trong từ điển dung để ghép từ, cho

Hình 4-4 Ví dụ về một văn phạm sinh cấu trúc pre-terminal

Không gian mật khẩu được sinh ra theo tiếp cận hai tương đối nhỏ so với phương pháp sinh không gian mật khẩu vét cạn Và nó sẽ được dung để làm đầu vào cho quá trình kiểm tra mật khẩu ứng cử trên GPU.

Hình 4-5 Một cây thứ tự ưu tiên

Xác định mật khẩu đúng trên GPU

Ý tưởng ban đầu là thực hiện xác định mật khẩu đúng trên không gian mật khẩu ứng cử Tuy nhiện do không gian mật khẩu ban đầu thường rất lớn, nên thời gian để thu gọn nó thành không gian mật khẩu ứng cử cũng rất lớn Mặt khác, số lượng mật khẩu ứng cử sau khi duyệt một lô cũng không nhiều, do đó ý tưởng ở đây là thực hiện phần việc xác định mật khẩu đúng cùng với phần việc sinh mật khẩu ứng cử. Cách làm này có lợi điểm là nếu mật khẩu đúng nằm ở các lô mật khẩu được duyệt sớm thì có thể dừng toàn bộ chương trình ngay lập tức, hạn chế đáng kể thời gian khôi phục mật khẩu ban đầu.

Nếu mật khẩu vừa sinh là mật khẩu ứng cử, luồng tương ứng sinh mật khẩu đó sẽ sử dụng khóa AES (được sinh ra cùng giá trị TestPVV từ hàm PBKDF2) để giải mã, như đã nói ở trên việc thực hiện giải mã toàn bộ tệp tin là không hiệu năng nên ta lựa chọn giải pháp thay thế là chỉ thực hiện giải mã trên một phần của tệp nén , có kích thước CHUNK chỉ cỡ 1 KB, sau đó giải nén và nhận dạng bản rõ để xác định mật khẩu ứng cử đó có phải là mật khẩu đúng hay không Theo mô tả ở hình 1, việc mã hóa được thực hiện sau khi nén, Winzip 9.0 sử dụng giải thuật mã hóa AES hoạt động trong chế độ đếm (AES- CTR), điều này đảm bảo cho kích thước dữ liệu trước và sau khi mã hóa là như nhau, thêm nữa phương thức nén mặc định được Winzip sử dụng là deflate [12].Winzip cũng lưu trong header của tệp nén tên của tập tin ban đầu, dựa vào tên này sẽ biết được định dạng của tệp tin như là doc, pdf hoặc txt (gọi chung là extension) và nó giúp ích cho công đoạn nhận dạng bản rõ ở pha 2 của bài toán

Các bước thực hiện ở pha 2 :

1 Luồng sinh mật khẩu ứng cử tiến hành giải mã dữ liệu đọc từ tệp nén sử dụng hàm Aes_ctr(AesKey,data_compressed_encrypted,CHUNK) với đầu vào là khóa AES vừa sinh ra, dữ liệu được đọc từ tệp nén Zip có độ dài CHUNK Hàm này thực hiện mã hóa một giá trị đếm tăng dần sử dụng khóa AesKey và sau đó thực hiện phép XOR với dữ liệu mã hóa, hàm trả lại chuỗi byte data_compressed có độ dài CHUNK, được xem như là dữ liệu bị nén. Chi tiết về hàm này đã đưa ra ở Chương 2, phần 2.3.2

2 Luồng sinh mật khẩu ứng cử tiếp tục giải nén phần dữ liệu data_compressed đầu ra ở bước trên sử dụng hàm inflate(data_compressed,CHUNK) Hàm này giải nén dữ liệu theo định dạng deflate, và nó có sẵn trong thư viện Zlib[13]. Hàm trả về chuỗi byte data, được xem như là dữ liệu chưa bị nén và chưa bị mã hóa Nếu dữ liệu bị nén không đúng định dạng thì hàm sẽ kết thúc hoặc

PDF header của nó luôn có dạng “%PDF-1.x” với x là số hiệu phiên bản 0,1, 7) Mặt khác, trong header của tệp nén cũng có trường filename (xem Phụ lục A) cho phép xác định được định dạng của tài liệu gốc Một khi biết được định dạng của tệp gốc ta sẽ đối sánh phần đầu của data với header tương ứng của định dạng đó Nếu chúng là như nhau, ta có thể kết luận data là dữ liệu gốc và mật khẩu ứng cử của luồng này sinh ra là mật khẩu đúng.

Giải thuật thực hiện

Như đã giải thích ở trên, giải thuật kiểm tra mật khẩu ứng cử được thực hiện song song, theo độ dài của mật khẩu Đầu tiên, giải thuật tính số lô cần thiết của một nhóm mật khẩu có độ dài xác định i Sau đó, với mỗi một lô p mật khẩu, giải thuật tính số thứ tự của các mật khẩu trong lô đó làm đầu vào cho hàm kiểm tra mật khẩu được thực hiện trên một tiến trình Mã giả của giải thuật như sau: found = 0; //found là biến toàn cục,= 1 nếu tìm ra mật khẩu đúng for i = 1 to k //duyệt từng độ dài mật khẩu

{ m = |S i | ; // tổng số mật khẩu cần thử có độ dài i p = thread_numbers; // số tiến trình // tối ưu trên GPU l = CEIL(m/ p); // Số lô của các mật khẩu có độ dài i /*duyệt song song từng lô, mỗi lô có p mật khẩu*/ for j = 0 to l - 1

{ base = j*p; // thứ tự mật khẩu đầu tiên của lô; for id = 0 to p-1 in parallel pw = GenPW i (base, id); //sinh mật khẩu

/*sinh giá trị TestPVV và khóa AES tương ứng với mật khẩu*/

(TestPVV,AesKey) = PBKDF2(pw, salt, dkLen); if (TestPVV = PVV)

/*giải mã dữ liệu data_compressed_encrypted độ dài CHUNK đọc từ tệp nén sử dụng khóa AesKey */ data_compressed =

Aes_crt(AesKey,data_compressed_encrypted,CHUNK);

/* giải nén dữ liệu vừa được giải mã */ data = inflate (data_compressed,CHUNK);

/* nhận dạng dựa vào extension của tệp gốc và một số header của các định dạng thông dụng*/ boolean ok = 0; switch (extension)

{ Case PDF : if (header(data)==headerPDF)ok=1; break;

Case DOC : if (header(data)==headerDOC)ok=1; break;

Case TXT :if (data có các ký tự văn bản) ok=1; break;

} if (ok) password[id] = guess_password; else password[id] = “”;

/* sau khi duyệt xong một lô mật khẩu thì kiểm tra kết quả trong lượt kiểm tra đó có mật khẩu đúng hay không, phần việc này thực hiện trên host*/

/* password là mảng chứa mật khẩu trả về, nếu khác kí tự “” thì có nghĩa nó là mật khẩu đúng*/ for id = 0 to p -1

{ found = 1; display password[id]; break;

/*nếu tìm thấy mật khẩu đúng thì dừng toàn bộ chương trình*/ if (found) break;

Hàm sinh GenPWi nhận đâù vào là thứ tự của mật khẩu đầu tiên của lô trong nhóm i (base) cùng với thứ tự trong lô id của mật khẩu cần kiểm tra Trong thực tế, thứ tự id được sinh ra một cách tự động khi kích hoạt kernel cho một lô, và tiến trình xử lý có thể lâý được giá trị này thông qua một số biến hệ thống của CUDA.

Hàm GenPWi (base, id) sẽ sinh ra mật khẩu tại vị trí base+id của nhóm, sau đó truyền mật khẩu vào hàm băm PBKDF2 để sinh khóa AesKey và một giá trịTestPVV tương ứng với mật khẩu đó Giá trị khóa này được đem so sánh với giá trị kiểm tra mật khẩu PVV lưu trong phần header của tệp nén để xác định xem mật khẩu vừa được sinh có phải là một mật khẩu ứng cử hay không song, mỗi tiến trình tự đảm nhiệm sinh mật khẩu và kiểm tra độc lập một mật khẩu, cho biết mật khẩu đó có phải là một phần tử trong tập các mật khẩu ứng cử hay không Vấn đề đặt ra là làm sao để mỗi tiến trình trên GPU sinh không lặp lại mật khẩu Giải thuật sinh xâu song song được thiết kế dựa vào định danh tiến trình Mỗi tiến trình có một đinh danh riêng id Ngoài id, còn cần thêm độ dài mật khẩu cần sinh i và vị trí cơ sở base Về lý thuyết, nếu số tiến trình trên GPU đúng bằng |PWi| thì tại một thời điểm mỗi tiến trình sẽ kiểm tra đúng một mật khẩu và base = 0. Nhưng nếu |PWi | lớn hơn số tiến trình tối ưu trên một GPU thì base là thứ tự của xâu đầu tiên của lô tiếp theo cần kiểm tra Hàm GenPWi(base,id) được định nghĩa như sau:

GenPWi (base, id) = xi−1 ã ã ã x0 x0 = S[((base + id) div n0 ) mod n] x1 = S[((base + id) div n1 ) mod n] xi−1 = S[((base + id) div ni−1 ) mod n]

2 Tiếp cận theo phương pháp phân tích cấu trúc mật khẩu

Giải thuật được chia thành hai phần chính: phần tuần tự thực thi trên CPU và phần song song thực thi trên GPU Phần thứ nhất sinh ra các cấu trúc dạng pre_terminal. Phần này được thực hiện tuần tự trên CPU Chi phí tính toán nằm chủ yếu ở phần 2 – với mỗi cấu trúc pre_terminal thu được, mang ghép nó với các từ trong từ điển có nghĩa để tạo thành mật khẩu thử, rồi xác định mật khẩu đó có phải là mật khẩu ứng cử hay không Do số lượng từ trong từ điển là khá lớn, dẫn đến số lượng mật khẩu thử sinh ra lớn vì vậy việc áp dụng năng lực tính toán của GPU để kiểm tra các mật khẩu thử này là phù hợp.

Phần thứ hai nhận đầu vào là các cấu trúc pre_terminal và từ điển, thực hiện ghép từ với từ điển để sinh mật khẩu thử và độc lập kiểm tra mật khẩu thử đó, bằng cách gọi hàm PBKDF2 như đã đề cập ở chương 2 Ta kí hiệu S là tập các từ trong từ điển có nghĩa, Sk là tập các từ trong từ điển có nghĩa, có độ dài từ là k, với k>= 1, nguyên và hữu hạn |Sk| là số lượng từ trong từ điển có nghĩa có độ dài là k Mã giả của giải thuật như sau: found =0 ; //found là biến toàn cục,= 1 nếu tìm ra mật khẩu đúng for each pre_terminal

/* với k là độ dài của các kí tự chữ cái trong pre_terminal*/ p = thread_numbers;

/* thread_numbers - số tiến trình song song tối ưu cho mỗi GPU*/ l = CEIL(m /p);

/* l – số lô các mật khẩu cần thực hiện tuần tự, hay số lần gọi nhân song song*/ for j = 0 to l – 1 { for id =0 to p-1 in parallel { base = j*p;

/*base là vị trí từ điển có nghĩa đầu tiên đối với lô thứ j, cần ghép với pre_terminal*/ guess_password = ghép pre_terminal với từ thứ

(id+ base) trong từ điển

(AesKey,TestPVV) = PBKDF2(guess_password,salt, dkLen); if (TestPVV == PVV)

/*giải mã dữ liệu data_compressed_encrypted độ dài CHUNK đọc từ tệp nén sử dụng khóa AesKey */ data_compressed =

Aes_crt(AesKey,data_compressed_encrypted,CHUNK);

/* giải nén dữ liệu vừa được giải mã */ data = inflate (data_compressed,CHUNK);

/* nhận dạng dựa vào extension của tệp gốc và một số header của các định dạng thông dụng*/ boolean ok = 0; switch (extension) {

Case PDF : if (header(data)==headerPDF)ok=1; break;

Case DOC : if (header(data)==headerDOC)ok=1; break;

Case TXT :if (data có các ký tự văn bản) ok=1; break;

} if (ok) password[id] = guess_password; else password[id] = “”;

/* password là mảng chứa mật khẩu trả về, nếu khác kí tự “” thì có nghĩa nó là mật khẩu đúng*/ for id = 0 to p -1

{ found = 1; display password[id]; break;

/*nếu tìm thấy mật khẩu đúng thì dừng toàn bộ chương trình*/ if (found) break;

} Đoạn mã giả trên cho thấy việc phân chia song song là theo dữ liệu, và với mỗi một pre_terminal cho trước, các tiến trình độc lập sinh xâu nhờ chỉ số định danh tiến trình – xâu sinh ra không bị lặp lại nếu từ trong từ điển là duy nhất Đồng thời đảm bảo mật khẩu có xác suất cao hơn được duyệt trước, nhưng nhược điểm của phương pháp này là nó phụ thuộc vào ngôn ngữ dùng để đặt mật khẩu – mỗi một ngôn ngữ cần có một từ điển của ngôn ngữ đó gồm các từ có nghĩa

Trong cả hai cách tiếp cận, sau khi thực hiện việc sinh và kiểm tra khóa,nếu mật khẩu sinh ra đúng là mật khẩu ứng cử thì luồng (tiến trình) đó tiếp tục gọi hàm Aes_crt sử dụng khóa AesKey để giải mã, gọi hàm inflate để giải nén và cuối cùng nhận dạng dựa trên header của một số định dạng thông dụng, để xác định mật khẩu đúng Khi đã tìm được mật khẩu đúng thì dừng toàn bộ công việc, do đó giảm thời gian đáng kể cho khôi phục mật khẩu trong những trường hợp khi mà mật khẩu đúng đặt cho tệp nén Zip rơi vào vùng có xác suất xuất hiện cao

THỬ NGHIỆM VÀ ĐÁNH GIÁ

Thử nghiệm

Toàn bộ 2 pha của bài toán khôi phục mật khẩu tệp nén Zip bao gồm giải thuật sinh xâu và kiểm tra mật khẩu ứng cử cho pha 1, và giải thuật xác định mật khẩu đúng cho pha 2 đã được xây dựng và triển khai thử nghiệm tại trung tâm tính toán hiệu năng cao trường Đại học Bách khoa Hà Nội Môi trường thử nghiệm bao gồm một máy tính PC được trang bị

– Bộ xử lý Intel Core 2 Quad Q8400 2.66 Ghz

– Hai card đồ hoạ kép NVIDIA GeForce GTX 295 (tổng cộng 4 GPU)

– Hệ điều hành Centos OS 5.3

Nhóm đã tiến hành thử nghiệm theo hai cách tiếp cận hình thành không gian mật khẩu phương pháp vét cạn và phân tích cấu trúc mật khẩu.

(*)Hiệu năng của bài toán được đánh giá theo 2 khía cạnh:

- Số lượng các khóa AES được sinh ra (chính là số lượng các mật khẩu ứng cử được sinh ra).

- Tốc độ khôi phục mật khẩu ban đầu của tệp nén ZIP được mã hóa (chính là toàn bộ bài toán, sau khi đã ghép pha thứ 2 của bài toán vào).

1 Tiếp cận vét cạn Đầu vào là tập ký tự chữ cái hoa, chữ cái thường và các chữ số S = {a − z, A − Z, 0

− 9} và số tiến trình chạy song song (hay số mật khẩu kiểm tra cùng lúc) là p 32768 Các giải thuật song song được cài đặt trên môi trường phần cứng như trên cho thấy tốc độ sinh khóa và kiểm tra khóa tăng rõ rệt so với việc thực hiện trên một tiến trình CPU Bảng 5-1 minh hoạ hiệu năng thực hiện công việc xác định tập mật khẩu ứng cử trên CPU và GPU. Độ dài mật khẩu Số lượng mật khẩu CPU 1GPU 2GPU 4GPU

Bảng 5-5 Thời gian xác định tập mật khẩu ứng cử trên CPU và GPU

Bảng 5-2 cho thấy số lượng khóa AES sinh ra trong một giây của GPU

Số lượng CPU/GPU Số lượng khóa sinh ra trong 1s

Bảng 5-6 Tốc độ sinh khóa trên GPU

Kết hợp thêm pha 2 và thực hiện trên GPU, ta có bảng thời gian khôi phục mật khẩu cho bài toán đặt ra như sau Độ dài mật khẩu Số lượng mật khẩu 1GPU 2GPU 4GPU

Bảng 5-7 Thời gian khôi phục mật khẩu trên GPU theo tiếp cận 1

Thời gian ở bảng trên được đo với giả thiết, tất cả mật khẩu ứng cử đều được giải mã, giải nén và nhận dạng bản rõ Như vậy nếu xét trung bình, thời gian để khôi phục một mật khẩu sẽ chỉ bằng một nửa thời gian ở trên.

2 Tiếp cận phân tích cấu trúc mật khẩu Đầu vào cần có hai loại từ điển: Một là loại từ điển chuyên dụng, gồm các mật khẩu thực để thống kê xác suất xuất hiện của các cấu trúc mật khẩu và của các kí tự chữ số và kí tự đặc biệt Tuy nhiên, việc có được các mật khẩu thực như vậy là điều không dễ dàng bởi các lý do về an toàn an ninh Do vậy trong thử nghiệm này, nhóm làm việc đã tạo ra một số cấu trúc dạng base cùng với xác suất của các kí tự chữ số, đặc biệt và của chính cấu trúc dạng base, để từ đó sinh ra cấu trúc dạng pre_terminal theo thứ tự xác suất giảm dần Dạng từ điển thứ hai là từ điển gồm các từ có nghĩa, nhóm sử dụng từ điển dic-0294.txt chứa 869229 từ Đây được coi là cuốn từ điển có số từ lớn nhất hiện nay Với cách thức tự đề xuất các luật như vậy, nó sẽ không ảnh hưởng tới hiệu năng khi đánh giá tổng quát chương trình bởi và việc sinh ra các cấu trúc pre-terminal là độc lập nhau.

Bảng 5-4 so sánh các kết quả thu được của hai tiếp cận sinh không gian mật khẩu. Giả sử mật khẩu đúng là 6class$$4, có độ dài 9, nếu dung phương pháp vét cạn thì phải duyệt 13,76.10 15 ( ~ 62 1 + 62 2 + … + 62 9 ) khóa mới có hy vọng tìm được mật khẩu đúng, rõ ràng điều này không thực tế Nhưng tiếp cận 2 có thể giải quyết được với cấu trúc mật khẩu 6L5$$4, cấu trúc này có thứ tự xác suất thứ 6, dùng từ điển dic-0294.txt, để sinh ra mật khẩu 6class$$4 và tổng số khóa phải duyệt là 469,332 khóa.

Số lượng GPU/CPU Số khóa (1) Thời gian (2)

CPU/GPU (TC1) 13,76.10 15 khóa Không tìm ra mật khẩu trong thời gian cho phép

Bảng 5-8 Bảng tốc độ sinh và duyệt khóa so sánh 2 cách tiếp cận

Khi bổ sung thêm công đoạn xác định mật khẩu đúng có thể làm bài toán dừng ngay lập tức mà không cần phải duyệt phần còn lại của không gian mật khẩu, bảng sau so sánh thời gian khôi phục mật khẩu giữa hai mật khẩu có xác suất xuất hiện cao (cấu trúc pre-terminal có thứ tự 6) và xác suất xuất hiện thấp hơn (cấu trúc pre-terminal có thứ tự 20).

Số CPU/GPU Số khóa (1) Thời gian (2) Số khóa (3) Thời gian (4)

Bảng 5-9 Thời gian khôi phục mật khẩu trên GPU theo tiếp cận 2

(1) Số lượng khóa phải duyệt cho đến cấu trúc có thứ tự 6

(2) Thời gian tương ứng để duyệt số khóa(mật khẩu) cho đến cấu trúc có thứ tự 6

(3) Số lượng khóa phải duyệt cho đến cấu trúc thứ tự 20

(4) Thời gian tương ứng để duyệt số khóa(mật khẩu) cho đến cấu trúc có thứ tự20

Đánh giá

Kết quả này cho thấy hiệu năng kiểm tra mật khẩu ứng cử tăng đáng kể (xấp xỉ 48 lần cho 1 GPU và 170 lần cho hệ thống 4 GPU) khi thực hiện trên GPU Giá trị 48 đến 170 lần là so sánh trên tổng thời gian tìm ra được toàn bộ mật khẩu ứng cử. Mặc dù chưa thử nghiệm được với những không gian mật khẩu có độ dài lớn, những thử nghiệm cho thấy khả năng ứng dụng cao của GPU trong bài toán khôi phục mật khẩu tệp nén.

Ta cũng nhận thấy thời gian khôi phục mật khẩu của bài toán (thực hiện cả pha 1 và pha 2) so với thời gian sinh tập mật khẩu ứng cử (thực hiện pha 2) không chênh lệch nhau nhiều, do bởi hai lý do

Thứ nhất, chi phí tính toán tập trung chủ yếu ở pha 1 – nơi có hàm băm với độ phức tạp lớn, trong pha 2, việc thực hiện chiếm chi phí ít trên tổng chi phí bởi vì chỉ giải mã, giải nén trên một phần rất nhỏ của tệp tin ZIP

Thứ hai, mỗi lần kích hoạt kernel ta kiểm tra được p mật khẩu đồng thời (p 32768) Số lượng mật khẩu ứng cử nếu có trong một lô như thế này cũng không nhiều vì theo lý thuyết sử dụng giá trị kiểm tra mật khẩu PVV sẽ giảm được không gian mật khẩu xuống 65536 lần.