Em chào các đại cao thủ, cứ tưởng các đại ca tận tình giúp đỡ chứ, đằng này lại bị cảnh cáo mới chán chứ.
Nói thẳng chút nhé, Dại ca K4i thì nói "Bạn có biết toán tử XOR trong C/C++ là gì không?" Vậy dại ca bóp đầu cái coi xem hiểu đc bao nhiêu C/C++ rồi ? ==>chán!
Bxll thì nghĩ cái Tin học thì có ai biết hết ? biết thôi cũng là quá cao siêu rồi. Bạn K4i hỏi nghe y như văn sĩ phòng thương mại của Microsoft thuyết trình ấy! 

Sorry đã send PM cho Anh FaL, Anh trách thế cũng đúng, có điều cái gì khó người ta đã cố gắng nhưng không làm được tức là vượt qua sức họ hoặc vượt qua khả năng của họ mới phải đi nhờ. Khó mới đi nhờ chứ đã làm được rồi thì chẳng nhờ các đại ca làm gì, và có thế mới nói rằng "...xin nhờ các Đại Cao Thủ giúp đỡ..." chứ nếu ko phải thế thì sẽ nói rằng "...đố các anh em làm đượpc đấy..." 2 câu trên có khác nhau không Anh? Thêm nữa vì giữ phép tôn trọng và hy vọng vào giúp đở cái mà Bxll không làm nổi nên Bxll mới gởi PM cho Anh và vì đã đọc bào viết của anh trên điễn đàn nên mới hy vọng nhiều vào anh như thế. Anh thử nghĩ xem - nếu Anh là Bxll? Anh sẽ giúp Bxll chứ?
 

theo yêu cầu đem chuỗi A ^ chuỗi B sẽ tìm ra chuỗi Key_C nhưng không cho phép nếu A Xor B ==' ' Msgbxo (" ");
vì các giá trị A và B luôn thay đổi theo mỗi lần nhập nên nếu Key_C đứng độc lập thì sao tìm (ko logic trong cấu trúc?) Vậy khi IDD_ma_Hoa phải kết hợp chuỗi nhập vào A kết hợp với Key đã cho để có chuỗi được mã hóa B, sau đó khi tiến hành Xor A với B thì mới có cơ sở tìm ra được Key_C chứ phải không Anh?
Nói chung cái đoạn tìm key là bxll không làm được, và giả thiết thêm nữa là nếu Key_C (cố định được gán trước) mà ta không biế`t là gì thì sao?  

Dialog_3 Tìm_Key: Key này là 1 giá trị kiểu chuỗi, cố định ví dụ như họ tên mình và được gán trước trong code chương trình
yêu cầu: nếu đem chuỗi cần mã hóa Xor với chuỗi đã được mã hóa thì tìm được key
Cụ thể là: chuổi nhập cần mã hóa [AAA] Xor [HHH] chuỗi đã được mã hóa sẽ tìm ra Key = [Tran_Van_A] đã được gán trước trong chương trình và key này là cố định.

Em làm nhưng không làm được, rất mong các cao thủ giúp em
 

Nhưng cái Dialog Tim key thì chịu. (Key là 1 giá trị được cố định trước trong chương trình ==> ko thay đổi được, trong khi giá trị plaintext nhập vào sẽ khác nhau mỗi lần nhập ==> giá trị sau khi mã hóa cũng sẽ thay đỗi), cụ thể:
Key_C="xin chao" //được gán trước, cố định trong code

Plaintext_A: nhập chuổi muốn mã hóa
Enziptext_B: chuỗi đã được mã hóa từ chuỗi A
theo yêu cầu đem chuỗi A ^ chuỗi B sẽ tìm ra chuỗi Key_C nhưng không cho phép nếu A Xor B ==' ' Msgbxo (" ");
vì các giá trị A và B luôn thay đổi theo mỗi lần nhập nên nếu Key_C đứng độc lập thì sao tìm (ko logic trong cấu trúc?) 

Em chỉ làm được Dialog1: Mã hóa chuỗi A nhập vào được chuỗi mã hóa B, Dialog2: Giải mã ngược lại. Em không làm được khi phối hợp mã hóa Chuỗi A + giá trị của Key_C để có được chuỗ Mã hóa B, từ đó ta Lấy Chuỗi A Xor với B thì sẽ tìm ra được Key_C đã gán trước trong code chương trình ?
 

EM hỏi thêm (Mở rộng): Nếu sau khi hoàn tất được yêu cầu trên (mã hóa: A + Key = B, vậy Kết hợp A ^ B ==>Key_C ) thì có thể mở rộng thêm chút là :
Coi như mình là người dùng, không biết giá trị Key_C, thể gán lặp for cho 2 biến i và j cho 2 thằng này chạy mụch đích của là sẽ đi tìm từng giá trị của Key? theo phương pháp Key_gen. Có được không các Anh?
 

Bạn mã hóa từ chuỗi A sang chuỗi B bằng cách nào?
Bạn thử ví dụ: chuỗi A là "ABCD", và key_C là "EFG" rồi bạn tìm chuỗi B từng bước xem sao. 

Giả sử
- Input String là: A
- Output String là: B

Mã hóa dùng phép toán xor, ta có thể tính toán độ dài của chuỗi con nhập vào để xor với key. Ví dụ:
- Chọn từng ký tự một của A để mã hóa (độ dài chuỗi con là 1)
- Chọn hai ký tự một của A để mã hóa (độ dài chuỗi con là 2)
....

Trong trường hợp này, chuỗi con phải có độ dài bằng độ dài của key. Chuỗi cha nếu như có độ dài không chia hết cho độ dài key, ta phải thêm phần padding (để độ dài A là bội của key)

Ta nhận thấy là dù key thế nào thì chuỗi A và B phải có độ dài bằng nhau. Nhận xét nữa là thứ tự chuỗi con của A và B là giống nhau.

Vậy thì ta sẽ chọn các chuỗi con tương ứng của A, B để xor với nhau -> key.

(Chú ý nữa là nếu key đúng thì khi xor đến lần thứ 2, ta sẽ nhận được key giống key của lần xor thứ 1, còn nếu key sai -> chuỗi con ta chọn là sai. Loại bỏ vòng lặp)

Ví dụ:
A = 0000
B = 1111
(key=1)
chuỗi con =1 -> key = 1

A = 1101
B = 0111
(key=10)
chuỗi con = 1 -> key1 = 1, key2 = 0 -> chuỗi con độ dài 1 là sai. Tăng giá trị chuỗi con
chuỗi con = 2 -> key1 = 10, key2 = 10 -> Đúng. Vậy key = 10

Số lượng chuỗi con là n. Vì vậy ta hoàn toàn có thể đoán được key. 

seraphpl wrote:

Bạn mã hóa từ chuỗi A sang chuỗi B bằng cách nào?
Bạn thử ví dụ: chuỗi A là "ABCD", và key_C là "EFG" rồi bạn tìm chuỗi B từng bước xem sao.
 

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.
 

facialz wrote:

seraphpl wrote:

Bạn mã hóa từ chuỗi A sang chuỗi B bằng cách nào?
Bạn thử ví dụ: chuỗi A là "ABCD", và key_C là "EFG" rồi bạn tìm chuỗi B từng bước xem sao.
 

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.
 

Tui nghĩ là mã hóa được. 1 cách tui nghĩ là:
giả sử A = 'ABCD', key = 'EFG'
Gọi dkey là độ dài của key. Ở ví dụ trên là 3
B[ i ] = A[ i ] xor key[(i-1) mod dkey+1]
(A[], B[], key[] là giá trị của A, B, key sau khi được chuyển sang hệ nhị phân, hoặc thập phân,....)[/i] 

seraphpl wrote:

facialz wrote:

seraphpl wrote:

Bạn mã hóa từ chuỗi A sang chuỗi B bằng cách nào?
Bạn thử ví dụ: chuỗi A là "ABCD", và key_C là "EFG" rồi bạn tìm chuỗi B từng bước xem sao.
 

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.
 

Tui nghĩ là mã hóa được. 1 cách tui nghĩ là:
giả sử A = 'ABCD', key = 'EFG'
Gọi dkey là độ dài của key. Ở ví dụ trên là 3
B[ i ] = A[ i ] xor key[(i-1) mod dkey+1]
(A[], B[], key[] là giá trị của A, B, key sau khi được chuyển sang hệ nhị phân, hoặc thập phân,....)[/i] 

Cách này có vẻ giống như là dùng key lặp đi lặp lại. Ví dụ khi mã hóa plaintext "ABCDEF..." thì key "EFG" sẽ được dùng như "EFGEFG...". Như thế chỉ cần biết khoảng 3 ký tự của plaintext là đủ để khám phá key, từ đó khám phá toàn bộ plaintext và phá tan mật mã một cách tầm thường.

Tui biết, ngay chính bản thân cái đề mã hóa nhiều plaintext bằng XOR với một key cố định đã là "củ chuối" lắm rồi. Nhưng cũng không vì thế mà ta còn ráng làm cho nó "củ chuối" hơn. ;-\ 

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.  

facialz wrote:

seraphpl wrote:

facialz wrote:

seraphpl wrote:

Bạn mã hóa từ chuỗi A sang chuỗi B bằng cách nào?
Bạn thử ví dụ: chuỗi A là "ABCD", và key_C là "EFG" rồi bạn tìm chuỗi B từng bước xem sao.
 

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.
 

Tui nghĩ là mã hóa được. 1 cách tui nghĩ là:
giả sử A = 'ABCD', key = 'EFG'
Gọi dkey là độ dài của key. Ở ví dụ trên là 3
B[ i ] = A[ i ] xor key[(i-1) mod dkey+1]
(A[], B[], key[] là giá trị của A, B, key sau khi được chuyển sang hệ nhị phân, hoặc thập phân,....)[/i] 

Cách này có vẻ giống như là dùng key lặp đi lặp lại. Ví dụ khi mã hóa plaintext "ABCDEF..." thì key "EFG" sẽ được dùng như "EFGEFG...". Như thế chỉ cần biết khoảng 3 ký tự của plaintext là đủ để khám phá key, từ đó khám phá toàn bộ plaintext và phá tan mật mã một cách tầm thường.

Tui biết, ngay chính bản thân cái đề mã hóa nhiều plaintext bằng XOR với một key cố định đã là "củ chuối" lắm rồi. Nhưng cũng không vì thế mà ta còn ráng làm cho nó "củ chuối" hơn. ;-\ 

hơ hơ, tui nghĩ là nên suy nghĩ kĩ trước khi nói
giả sử key là "EFGEFGEFGEFGEFGEFGEFGEFGEFGEFGEFGEFGK" thì tui không biết là bạn giải cái key khi biết 3 kí tự như thế nào. 

facialz wrote:

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.  

=> Củ chuối không có nghĩa là không mã hóa được 

Lúc này, B [ i ] = A [ i ] xor key [f(i)]
Tui chưa thấy ra nó củ chuối chỗ nào, bạn vào chỉ ra xem. 

"EFGEFGEFGEFGEFGEFGEFGEFGEFGEFGEFGEFGK" là key có độ dài 37 ký tự. Trong trường hợp này cần biết khoảng 37 ký tự của plaintext để có thể khám phá toàn bộ key. Nếu plaintext dài hơn 37 ký tự thì mật mã vẫn bị phá một cách ngớ ngẩn.

Bác đừng nghĩ ra thêm cái key 100 ký tự nữa nhé. 100 hay 1 triệu cũng thế thôi.
 

seraphpl wrote:

facialz wrote:

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.  

=> Củ chuối không có nghĩa là không mã hóa được 

Nó "củ chuối" là một chuyện, không mã hóa được là chuyện khác.
 

Khi mã hóa bằng phép tính A ^ B thì A và B phải có cùng độ dài.
 

seraphpl wrote:

Lúc này, B [ i ] = A [ i ] xor key [f(i)]
Tui chưa thấy ra nó củ chuối chỗ nào, bạn vào chỉ ra xem. 

Công thức này đã khá hơn. Muốn biết nó "củ chuối" không thì còn phải phân tích, nhưng chắc chắn là lạc đề. Vì đề bài là lấy plaintext XOR với key chứ không XOR với một chuỗi được sinh ra từ key. Và hai cách này là cực kỳ khác nhau. Bác hiểu chưa? 

facialz wrote:

"EFGEFGEFGEFGEFGEFGEFGEFGEFGEFGEFGEFGK" là key có độ dài 37 ký tự. Trong trường hợp này cần biết khoảng 37 ký tự của plaintext để có thể khám phá toàn bộ key. Nếu plaintext dài hơn 37 ký tự thì mật mã vẫn bị phá một cách ngớ ngẩn.

Bác đừng nghĩ ra thêm cái key 100 ký tự nữa nhé. 100 hay 1 triệu cũng thế thôi.
 

Bạn dùng cái gì để biết là key có 3 kí tự, 37 kí tự, 100 kí tự hay 1 triệu kí tự khi mà bạn đang đi tìm nó ) 

facialz wrote:

seraphpl wrote:

facialz wrote:

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.  

=> Củ chuối không có nghĩa là không mã hóa được 

Nó "củ chuối" là một chuyện, không mã hóa được là chuyện khác.
 

Mời bạn xem lại câu khẳng định màu đỏ của chính mình. 

facialz wrote:

Khi mã hóa bằng phép tính A ^ B thì A và B phải có cùng độ dài.
 

Cái chúng ta đang bàn luận là A và key, chớ không phải A và B 

facialz wrote:

seraphpl wrote:

Lúc này, B [ i ] = A [ i ] xor key [f(i)]
Tui chưa thấy ra nó củ chuối chỗ nào, bạn vào chỉ ra xem. 

Công thức này đã khá hơn. Muốn biết nó "củ chuối" không thì còn phải phân tích, nhưng chắc chắn là lạc đề. Vì đề bài là lấy plaintext XOR với key chứ không XOR với một chuỗi được sinh ra từ key. Và hai cách này là cực kỳ khác nhau. Bác hiểu chưa? 

Mời bạn đọc kĩ lại cái phép XOR 

seraphpl wrote:

Bạn mã hóa từ chuỗi A sang chuỗi B bằng cách nào?
Bạn thử ví dụ: chuỗi A là "ABCD", và key_C là "EFG" rồi bạn tìm chuỗi B từng bước xem sao.
 

Trường hợp này tui nghĩ là không mã hóa được vì key ngắn hơn plaintext.
 

Tui nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì cũng bằng 00..0010111, rồi lúc đó thì muốn xor thế nào mà chẳng đc ) 

seraphpl wrote:

Tui nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì cũng bằng 00..0010111, rồi lúc đó thì muốn xor thế nào mà chẳng đc ) 

Tui lại nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì không bằng 00..0010111, bởi vì chúng là 2 string khác độ dài.
 

Do đó khi key ngắn hơn plaintext, phép XOR không thể thi hành. Nếu nối thêm vào một string 00..00 để làm cho key dài bằng plaintext thì phép XOR sẽ thực hiện được, về hình thức, nhưng không làm thay đổi bản chất vấn đề là đoạn plaintext được XOR với 00..00 sẽ không được mã hóa. Bản chất vấn đề cũng không thay đổi nếu phép "nối dài bằng 00...00" được thay bằng phép "lặp đi lặp lại key đến khi thu được một string dài bằng plaintext". Trong cả 2 trường hợp, độ bất định của key không thể tăng lên mà độ phức tạp cũng chẳng cứu vãn được điều gì.
 

Cách duy nhất để làm đúng, mà vẫn đảm bảo theo sát phương trình plaintext ^ ciphertext ^ key == 0, là dùng 1 key dài hơn hoặc bằng plaintext, hoặc hạn chế plaintext để nó không dài hơn key
 

facialz wrote:

seraphpl wrote:

Tui nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì cũng bằng 00..0010111, rồi lúc đó thì muốn xor thế nào mà chẳng đc ) 

Tui lại nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì không bằng 00..0010111, bởi vì chúng là 2 string khác độ dài.
 

Đã chuyển sang nhị phân rồi thì 10111 = 00..0010111 (Đây là 2 số nhị phân chứ không phải 2 string) 

facialz wrote:

Do đó khi key ngắn hơn plaintext, phép XOR không thể thi hành. Nếu nối thêm vào một string 00..00 để làm cho key dài bằng plaintext thì phép XOR sẽ thực hiện được, về hình thức, nhưng không làm thay đổi bản chất vấn đề là đoạn plaintext được XOR với 00..00 sẽ không được mã hóa. Bản chất vấn đề cũng không thay đổi nếu phép "nối dài bằng 00...00" được thay bằng phép "lặp đi lặp lại key đến khi thu được một string dài bằng plaintext". Trong cả 2 trường hợp, độ bất định của key không thể tăng lên mà độ phức tạp cũng chẳng cứu vãn được điều gì.
 

Ngay từ đầu, nên bám sát cái đề, "abcd...k123" cũng được gọi là khác "abcd...k456" và hoàn toàn có thể nói "abcd...k456" là chuỗi mã hóa của "abcd...k123".  

Còn việc làm độ bất định của key tăng lên nhiều hay ít thì lại là 1 vấn đề khác.  

facialz wrote:

Cách duy nhất để làm đúng, mà vẫn đảm bảo theo sát phương trình plaintext ^ ciphertext ^ key == 0, là dùng 1 key dài hơn hoặc bằng plaintext, hoặc hạn chế plaintext để nó không dài hơn key
 

key có độ dài nhỏ hơn độ dài plaintext thì cái phương trình plaintext ^ ciphertext ^ key = 0 cũng chẳng sai. 

Cuối cùng, key càng dài thì kết quả càng khó đoán hơn là key ngắn. Nhưng ngược lại, key ngắn thì dung lượng để lưu key là nhỏ hơn key dài. Và trong thực tế, để mã hóa dữ liệu lớn thì chẳng lẽ cái chương trình mã hóa lại có dung lượng lớn hơn dữ liệu cần mã hóa.  

Và tui nghĩ là
plaintext+key+f() = ciphertext (Với f() là một hàm để mã hóa) 

seraphpl wrote:

facialz wrote:

seraphpl wrote:

Tui nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì cũng bằng 00..0010111, rồi lúc đó thì muốn xor thế nào mà chẳng đc ) 

Tui lại nghĩ là "EFG" giả sử chuyển sang nhị phân là 10111 thì không bằng 00..0010111, bởi vì chúng là 2 string khác độ dài.
 

Đã chuyển sang nhị phân rồi thì 10111 = 00..0010111 (Đây là 2 số nhị phân chứ không phải 2 string) 

Số nào cũng biểu diễn bằng string. Số nhị phân không phải là ngoại lê.
 

Và khi bác coi chúng là số, bác có thu được gì mới mẻ đâu ngoài việc thực hiện được phép XOR (hình thức) với 00..0010111.
 

seraphpl wrote:

facialz wrote:

Do đó khi key ngắn hơn plaintext, phép XOR không thể thi hành. Nếu nối thêm vào một string 00..00 để làm cho key dài bằng plaintext thì phép XOR sẽ thực hiện được, về hình thức, nhưng không làm thay đổi bản chất vấn đề là đoạn plaintext được XOR với 00..00 sẽ không được mã hóa. Bản chất vấn đề cũng không thay đổi nếu phép "nối dài bằng 00...00" được thay bằng phép "lặp đi lặp lại key đến khi thu được một string dài bằng plaintext". Trong cả 2 trường hợp, độ bất định của key không thể tăng lên mà độ phức tạp cũng chẳng cứu vãn được điều gì.
 

Ngay từ đầu, nên bám sát cái đề, "abcd...k123" cũng được gọi là khác "abcd...k456" và hoàn toàn có thể nói "abcd...k456" là chuỗi mã hóa của "abcd...k123".  

Tùy bác. Bác coi mã hóa một nửa, thậm chí không mã hóa là những dạng đặc biệt của mã hóa cũng được. Chẳng qua cũng chỉ là một định nghĩa. Nó cũng chẳng đem lại được định lý nào mới mà chỉ đem đến sự nhập nhằng.
 

seraphpl wrote:

Còn việc làm độ bất định của key tăng lên nhiều hay ít thì lại là 1 vấn đề khác.  

Và đây, sự nhập nhằng. Độ bất định và độ phức tạp để đánh giá tính bảo mật. Khi viết chương trình mã hóa, người ta mong đợi ở đó tính bảo mật. Mã hóa mà lờ bảo mật đi thì mã hóa làm gì?
 

Luôn tiện, độ bất định của key không tăng, chứ không phải là nó tăng nhiều hay tăng ít. E rằng chỗ "nhập nhằng" này hơi bị cơ bản đấy.
 

seraphpl wrote:

facialz wrote:

Cách duy nhất để làm đúng, mà vẫn đảm bảo theo sát phương trình plaintext ^ ciphertext ^ key == 0, là dùng 1 key dài hơn hoặc bằng plaintext, hoặc hạn chế plaintext để nó không dài hơn key
 

key có độ dài nhỏ hơn độ dài plaintext thì cái phương trình plaintext ^ ciphertext ^ key = 0 cũng chẳng sai. 

Sự nhập nhằng được lặp lại. "Mã hóa để bảo mật" bị nhập nhằng với "mã hóa chẳng để làm gì". Đúng đắn ở mấy phép XOR này là hình thức bên ngoài. Sai lầm ở trong nội dung. Tui đã nói từ bài trước rùi đó.
 

seraphpl wrote:

Cuối cùng, key càng dài thì kết quả càng khó đoán hơn là key ngắn. Nhưng ngược lại, key ngắn thì dung lượng để lưu key là nhỏ hơn key dài. Và trong thực tế, để mã hóa dữ liệu lớn thì chẳng lẽ cái chương trình mã hóa lại có dung lượng lớn hơn dữ liệu cần mã hóa.  

Sự nhập nhằng lặp lại một lần nữa. Thực tế cái gì ở đây? Trong thực tế, khi đã mã hóa thì người ta quan tâm đến tính bảo mật. Khi làm ra một thuật toán "mã hóa" mà một key có độ dài thực tế không mã hóa được dữ liệu có độ dài thực tế thì thực tế hơn cả là tìm thuật toán khác. Hoặc trong trường hợp bị khống chế bởi điều kiện của đề bài như trường hợp này, thì chỉ ra giới hạn của thuật toán của mình. Mà trong trường hợp này giới hạn ấy là độ dài của dữ liệu. Còn cố định nghĩa lại khái niệm "mã hóa" để la lớn rằng "thuật toán của tui vẫn là thuật toán mã hóa còn nó có bảo mật hay không lại là chuyện khác", cái đó e rằng không phải là thực tế.
 

seraphpl wrote:

Và tui nghĩ là
plaintext+key+f() = ciphertext (Với f() là một hàm để mã hóa) 

Kẻ tấn công biết hàm f. Và f không có đối số thì chỉ là một hằng số. Và nếu giả sử f có đối số mà đối số ấy không phải là key thì kẻ tấn công cũng biết luôn đối số này. Hi vọng bác đã tính đến những điều đó khi phát biểu ý nghĩ trên. 

facialz wrote:

seraphpl wrote:

Và tui nghĩ là
plaintext+key+f() = ciphertext (Với f() là một hàm để mã hóa) 

Kẻ tấn công biết hàm f. Và f không có đối số thì chỉ là một hằng số. Và nếu giả sử f có đối số mà đối số ấy không phải là key thì kẻ tấn công cũng biết luôn đối số này. Hi vọng bác đã tính đến những điều đó khi phát biểu ý nghĩ trên. 

Tại sao kẻ tấn công biết hàm f()?
Cái f() ở bài trước là tui chỉ giả sử đơn giản thôi, còn lại thì có muôn vàn cách để làm ra f(),
Tui đâu có pâhn tích gì cái f(). Tui chưa hiểu rõ ràng ý của bạn về phần này? 

plaintext+key+f() = ciphertext (Với f() là một hàm để mã hóa)

plaintext + ciphertext + f(key) == 0 (2)