banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: StarGhost  XML
Profile for StarGhost Messages posted by StarGhost [ number of posts not being displayed on this page: 0 ]
 
@eff3: good point, nhưng mà không phải do mình không thích, mà căn bản sự thật nó là như thế. Số lượng người không thích thì mình cho rằng nhiều vô kể.

@hvthang: vậy bạn cho mình hỏi là trong DSA thì những bước mà bạn cho là cơ bản đó nằm ở chỗ nào (mã hoá, giải mã, so sánh hash)? Còn chuyện lược đồ trên wiki đúng hay sai thì mình cũng không muốn tranh cãi vì lí lẽ đã đưa ra ở trên. Nói chung mình thấy nhiều người vì sự phổ biến của RSA nên hay bị nhầm lẫn giữa RSA signature scheme và cái gọi là digital signature.
@hvthang: không (đúng hơn là chưa) tồn tại khái niệm mã hoá và giải mã trong các thuật toán thực hiện chữ kí điện tử (digital signatures). Nói chung là cả cái định nghĩa đó mình cho là không có chỗ nào đúng. Bạn có thể tham khảo http://en.wikipedia.org/wiki/Digital_signature#Definition để biết một cách informal về chữ kí điện tử (Lưu ý: cái hình đi kèm thì không đúng).

vitcon01 wrote:

Chữ ký điện tử được tạo ra bằng cách áp dụng thuật toán băm một chiều trên văn bản gốc để tạo ra bản phân tích văn bản (message digest) hay còn gọi là fingerprint, sau đó mã hóa bằng private key tạo ra chữ ký số đính kèm với văn bản gốc để gửi đi. Khi nhận, văn bản được tách làm 2 phần, phần văn bản gốc được tính lại fingerprint để so sánh với fingerprint cũ cũng được phục hồi từ việc giải mã chữ ký số  

Đây chỉ là một thiết kế của thuật toán tạo chữ kí điện tử, chứ không phải là chữ kí điện tử bắt buộc phải tạo ra bằng cách này. Và mình thấy phần dùng từ cũng chưa chuẩn.

tweru wrote:

Theo kiến thức mình được biết xin trả lời bạn 2 câu trên như sau

1. Cơ chế đảm bảo dữ liệu không bị thay đổi là cơ chế tin cậy ( Confidentialy)
Xem qua hình này bạn sẽ hiểu chức năng tin cậy như thế nào


 

---> Đề nghị bạn dùng đúng thuật ngữ
Trong hình trên cũng có vài chỗ khó hiểu, ví dụ như Z, EP, DP, và E[PR_a, H(M)]. Bạn làm đề tài gì về chữ kí điện tử vậy, có thể gửi cho mình 1 bản được không (pm).
@panfider: mình nhớ là mình có gửi cho bạn một tài liệu về phong cách viết chương trình C. Ngoài ra, mình đề nghị bạn tìm cách cải thiện tiếng Anh của bản thân. Một chương trình + lỗi đơn giản thế này mà bạn không debug ra thì mình không hiểu độ tin cậy của các đoạn mã của bạn là được bao nhiêu.
@faithhw: mình chưa làm câu XOR. Tuy nhiên điểm quan trọng nhất là bạn phải có một quyển từ điển (hoặc ít ra là một danh sách các từ tiếng Anh thông dụng), như gợi ý. Tốt nhất bạn nên viết chương trình giải mã một cách tự động hơn là ngồi đoán.
"LOCAL STUFF lol"
Hình như có một số bạn bị ngộ nhận giữa việc tồn tại nhiều dự án về cloud, việc người ta nghe nói nhiều đến cloud, với sự hứa hẹn mức độ thành công của cloud.

Riếng bản thân mình cho rằng cái điều khó khăn nhất trong commercial cloud computing không phải là về infrastructure hay performance, mà là về security. Bản thân security research về cloud vẫn còn quá nhiều vấn đề phải giải quyết, vì vậy mình chưa nhìn ra được bất cứ một sự hứa hẹn nào về cloud trong tương lai gần.

Ngay cả bản thân các công ty như MS, google, yahoo mặc dù đang phát triển cloud nhưng mình không chắc đến bao giờ họ mới cho ra cái cloud nào ổn ổn. Cái này mình đã trực tiếp trao đổi với một bác làm ở MS research và một prof ở USyd nên cũng biết chút đỉnh.
@faithhw: sorry dạo này mình travel hơi nhiều nên không thường xuyên check Internet. Tuy nhiên mình vẫn đang theo dõi chủ đề, và thỉnh thoảng vẫn tiếp tục chơi.
@Xcode: nghiên cứu rất thú vị và cũng rất tốn kém về mặt thời gian và khí lực. Trong Understanding the Linux kernel 2nd có 1 chương nói sơ qua về linux networking nhưng cũng đủ để hình dung ở một mức độ nào đó. Tuy nhiên để hiểu rõ tường tận thì, ngoài việc tham khảo mớ mailing-lists như anh conmale, theo kinh nghiệm của mình thì không còn cách nào hay hơn là debug kernel, ngồi ngắm mớ source code không thì cũng buồn ngủ lắm.

Ngoài ra trước khi tìm hiểu về vấn đề này mình nghĩ bạn nên nắm rõ nguyên lý hoạt động của Linux, những thứ đại loại như memory management, process scheduling, ipc, syscalls, interrupt handlings, timers, các loại modules, streaming, caching, buffering. Những thứ này trong quyển sách kể trên có bàn khá rõ.

Hope that helps.
@panfider: hỏi nhầm đối tượng rồi bạn. Bản thân mình còn chẳng ai tuyển, thất nghiệp chổng vó, thì mình còn đi tuyển ai. ^^
Đây là một mô tả ngắn về phong cách viết một chương trình bằng C.
http://www.chris-lott.org/resources/cstyle/indhill-cstyle.html

@Doorkeeper: good english có lẽ đại loại như IELTS 6.5/TOEFL iBT 100. 281 thấy sao?
@panfider: mình chỉ có một nhận xét sau, chủ yếu là về cách trình bày mã nguồn: bạn nên tham khảo các source về c (vd: linux kernel source) để biết convention của cộng đồng. Như thế người khác xem mã nguồn của bạn sẽ có thiện cảm hơn.
@motminhanh: cloud computing còn đang trong cái nôi phát triển về mọi mặt, trong tương lai gần bạn khó mà có thể làm gỉ được. Nếu làm về mảng này có lẽ chỉ đi lên PhD thì có tương lai, chứ về mặt ứng dụng thì khó sống.

Nếu bạn muốn làm về security của cloud computing thì có một số các vấn đề mở khá phổ biến như SLA, resource allocation, separation of resources, fairness, etc.
Số là mình cần thiết lập một hệ thống camera an ninh cho cửa hàng và quản lý nó qua Internet. Tuy nhiên mình không có kinh nghiệm trong việc chọn loại camera cũng như phần mềm quản lý sao cho nó hoạt động ổn định và thoải mái.

Nếu bạn nào có kinh nghiệm trong vấn đề này thì mình xin chút ý kiến nhé.

Cám ơn nhiều.
Xin lỗi các bạn, cái site này thỉnh thoảng lại bị lỗi không truy cập được mysql, nên không hiện challenges ra. Tuy nhiên các bạn có thể google cryptolib challenges rồi vào cache để xem, hi vọng là vẫn còn ở đó. Hiện tại có tất cả 11 challenges, không theo thứ tự khó dễ nào cả.

Tuy nhiên, challenge nào điểm càng cao thì càng khó, vậy thôi.

@faithhw: mình chờ bạn tham gia thảo luận.
Mình không rõ config của debian thế nào, nhưng mình nghĩ thông thường có 2 cách nhận driver trong khi boot. Một là khi bạn compile kernel thì bạn nhét hết vào kernel (bzImage). Hai là bạn tạo thành modules riêng rẽ, sau đó mount những modules này vào trong ramdisk để kernel có thể nhận được mà plug vào. Không biết bạn đã dùng cách nào?
Mới đây mình ngồi google may sao vớ được 1 trang web có vài challenges về mã hoá, na ná cái Krypton của Overthewire, nhưng có lẽ hơi advanced hơn 1 chút: http://cryptolib.com/challenges.php

Mình rất khuyến khích các bạn tham gia, đặc biệt những bạn yêu thích cipher cryptanalysis. Topic này mình lập ra vì thấy cũng có một số bạn trên HVA có hứng thú với crypto, và để thảo luận về các mẹo cũng như khó khăn khi các bạn giải các challenges đó.

Chúc vui.
@nhanth87: mình nghĩ bạn nên google những từ khoá như oracle hay side channel để hiểu rõ hơn về mặt khái niệm trước khi thảo luận.

@mrro: paper rất hay. Hôm trước mrro có nói sẽ trình bày về một kĩ thuật tấn công tương tự chopchop, có lẽ là cái này. Đúng là có tương tự nhau, mặc dù chopchop hạn chế hơn padding oracles, vì trong wireless encryption thì plaintext còn được hỗ trợ CRC và MIC nữa.
OK, bạn đã đưa ra lập luận của mình, bây giờ mình muốn hỏi bạn một số vấn đề sau:
Câu 1. Theo bạn thì để một máy trong mạng hoạt động tốt, thì địa chỉ IP của nó phải thoả mãn (những) điều kiện gì? Gợi ý: nên nhớ lại tại sao người ta cần địa chỉ IP, nó dùng để làm gì.

Câu 2. Một địa chỉ IP thường chia ra làm 2 phần: network và host. Tại sao bạn nói phần network cần 128 mạng mà lại suy ra phần host cần 8 bit? Tại sao lại là "2^8 - 2" mà không là "2^8"?

Câu 3. Câu này căn bản giống hệt câu trước, chỉ khác số liệu. Bạn làm đúng câu trước thì sẽ làm được câu sau.

geminious wrote:
Mỗi ngành có 1 yêu cầu nhất định. Mình đang theo học CNTT ở 1 trg đh và theo mình thấy là ngành này yêu cầu mức độ tư duy logic và toán học rất cao cộng thêm 1 chút tố chất năng khiếu. Nếu k có năng khiếu và khả năng tư duy mạnh, bạn có thể học rất chăm nhưng kết quả đạt được lại chỉ dừng ở 1 mức độ nào đó thôi. smilie Còn về QTKD thì mình chưa có điều kiện tiếp xúc. Bạn nên nghiên cứu thật kỹ về các khả năng cũng như tiềm năng của mình trong từng lĩnh vực. Đừng quá chạy theo xu hướng vào ngành hot mà bỏ quên thực lực của mình. Chắc năm nay bạn thi đh smilie chúc bạn thi tốt và vào đc trg phù hợp với mình smilie 


Ah, năng khiếu ở đây là gì hả bạn? Có thể nói rõ hơn được không? Mình cũng chưa biết là ngành CNTT thì cần năng khiếu gì smilie
mrro à, nếu attack đó là mathematical attack thì mình khuyên mrro nên submit paper vào một crypto conference, như thế record của bạn sẽ ổn hơn. Tất nhiên mình không có ý trọng cái danh trong research, nhưng mà mình cho rằng đây là một convention tốt, it nhất ở khoản peer review.
Chà, tên đề tài hay quá. Chắc "bà cô" của bạn là fan của linux, nên chỉ "bảo mật" linux network, còn Windows network, Mac network, etc. thì không, hay cả heterogeneous network cũng không.
@admm: bạn cũng phải thông cảm cho quanta thôi, vì số vụ như bạn ngày nào (thậm chí có khi giờ nào) cũng có, và trong rất nhiều trường hợp OPs cứ mặc kệ không chịu sửa lại bài viết nên các mod rất bực mình.

Nói chung mình có nhận định chủ quan rằng có lẽ bạn ít khi tham gia các diễn đàn nghiêm chỉnh trên Internet nên còn chưa rõ họ coi trọng nội quy ra sao. Cũng có thể mình nhận định sai.

p/s: Còn chuyện mấy tay IT chỗ bạn bảo rằng HVA trả lời nhiệt tình thì không hoàn toàn đúng đâu. Mấy câu hỏi kiểu này vào HVA thì đều bị wwwected ra google hết. Cá nhân mình khuyên bạn nên tìm hiểu Thunderbird thay vì MS Outlook, vì mình thấy nó dễ dùng hơn và tiện lợi hơn.
Dưới đây là một số bổ sung cho post của bạn myquartz. Các giải thích toán học quá dài dòng nên mình đành bỏ qua, dù vậy chúng rất hiển nhiên.

myquartz wrote:
Trong RSA, có private key ko tính toán được public key, và ngược lại, 2 con số này (2 cái key thực ra là 2 con số nguyên tố), nó quan hệ toán học với nhau đối xứng thì mới thành cặp key, nếu không phải thì ko thể thành cặp. Nếu xét về mặt toán thì cái nào là public, cái nào là private cũng được, quan trọng là giữ bí mật cái nào thì cái đó là private key, vậy thôi. (tham khảo http://en.wikipedia.org/wiki/RSA ).
Nguyên lý của nó, là bạn mã hoá bằng public thì giải mã bằng private, và ký bằng private (thực chất là mã hoá chuỗi hash của plain text), sẽ giải mã được bằng public, so cái chuỗi hash được giải mã đó với hash của plain text nhận được thì biết là đúng chữ ký hay không.
Hàm của nó kiểu:
e = c(p,pub)
=> p = c(e,pv).
<=>
e = c(p,pv)
p = c(e,pub)

Trong đó: e = bản đã mã, hoặc ký, p = plain, pv: private, pub = public. c là hàm mã hoá.

Về việc ko thể tính toán, nói đúng hơn ko phải ko tính ra được, mà là thời gian tính nó rất dài với năng lực của máy tính hiện tại (kể cả siêu máy tinh) thành ra là impossible. Tỉ dụ nếu độ dài 512bit (số 512bit độ dài, to lắm đấy, so với máy tính 64bit thì biết), ng ta nói rằng một số siêu máy tính trên thế giới đã có thể tính toán được ra cặp đối xứng đó, trong vòng 1 vài năm. Nhưng, với 1024, 2048 hoặc hơn, thì phải hàng ngàn, triệu năm.
RSA dựa vào nguyên tắc là việc tính toán ra số nguyên tố cực lớn là một việc cực kỳ vất vả. Nếu bẻ gãy được việc này, giảm thời gian đó xuống thì sẽ giải mã được RSA.
Cũng vì điều này, giải mã, mã hoá bất đối xứng như RSA, hay cả DSA là một việc tốn kém năng lực của máy tính, người ta không dùng nó để mã hoá cả 1 đoạn text dài, chỉ mã hoá hoặc ký vào symetric key hay là hash thôi, hay ký trong certificate hash. Symetric key này sẽ tiếp tục làm cái việc là mã hoá plain text bằng 1 block cipher có tốc độ cao hơn. Session key chính là Symetric key, lộ cái này thì phiên SSL cũng coi như là bị giải mã.
 

--> Mình nghĩ bạn myquartz đang nói đến e và d trong RSA. Như vậy mình cho rằng khó có khả năng đây là 2 số nguyên tố.

--> Thực ra việc bẻ khóa RSA không lâu đến vậy. Với 512bit thì chỉ cần ba trăm máy tính (thời cách đây chục năm) trong khoảng vài tháng là đã ra. Còn nếu nói siêu máy tính thì chỉ trong cấp độ tuần. Đấy là mình nói về mặt tổng quát, tức là bẻ bất cứ khóa 512 bit nào, chứ không tính đến một số loại khóa bẻ nhanh hơn. Hiện nay có bộ thuật toán *NFS giải quyết vấn đề này nhanh nhất (mà theo mình biết VN ta có bác rd là chuyên gia, đã từng viết vài papers cải tiến vài khâu quan trọng).

--> Đoạn này mình không hiểu lắm, ý bạn có phải là nếu mình muốn tìm một số nguyên tố có độ dài 500 bits là rất vất vả, và RSA dựa vào nguyên tắc này? Nếu vậy thì mình không đồng ý lắm. Trên thực tế, RSA không dựa vào bất cứ nguyên tắc nào liên quan đến số nguyên tố cả.

--> "điều này" = "việc tính toán số nguyên tố lớn rất vất vả"? Mình nghĩ chưa chắc, vì khi mã hóa hoặc giải mã có động gì đến số nguyên tố đâu.

mrro wrote:
@StarGhost: mình đang nói đến thông tin nằm trong file chứa private key, còn SG lại nói về lý thuyết. 

À à, thế mình lại sai rồi. Cái này mình không nhớ rõ. Sau này mình không bàn luận bừa nữa. smilie

mrro wrote:

Dẫu vậy đây cũng là một vấn đề hay, mình không biết Elgamal và Cramer-Shoup nên không dám nói bừa, mình có biết chút ít về RSA nên thử bàn xem: liệu biết (n, d) có thể tính được e hay không? Đương nhiên lúc này e phải thỏa mãn những tính chất khi người ta chọn e trong thực tế, ví dụ như e phải rất nhỏ.  

Hì hì, nếu nói như mrro thì chả cần có private key mình cũng biết e là gì (với xác suất cao), vì hầu hết bây giờ người ta toàn dùng e = 65537. Lí do: i) 65537 đủ nhỏ mà cũng đủ lớn (để encrypt nhanh) ii) 65537 = 2^16+1 (để tính toán nhanh) iii) 65537 là một số nguyên tố (để chọn p,q nhanh).
Còn Elgamal và Cramer-Shoup thì hiển nhiên không được, vì mapping từ PubKey Set -> PriKey set không phải là one-to-one.

mrro wrote:
he he he nếu mà cái chỗ màu đỏ đúng thì còn gì hệ mã khóa công khai nữa bạn. ngược lại thì đúng, nghĩa là có private key thì sẽ tính được public key, nhưng mà nhìn vào public key không thể nào tính được private key.
 


Ậy ậy, bạn mrro cẩn thận chỗ này. Trong security definition của public-key cryptography không có yêu cầu cái này, và cái này cũng không đúng (vd: RSA, Elgamal, Cramer-Shoup)
Không cài lại được thì ít nhất recompile lại kernel đi (hoặc nếu đã backup image ở đâu đó thì paste lại, kể cả file initrd luôn), để đề phòng những vấn đề như Mr.Khoai đề cập ở trên. Ngoài ra kiểm tra scripts của tất cả start up services để loại bỏ khả năng script của hacker tự động khởi động cùng hệ thống.
Mấy hôm nay bận quá, bây giờ mới mày mò tiếp được.

@Mr.Khoai: nice explanation.

@all: thực ra cái điều kiện mình nói ở trên là dành cho Linux (2.6.25.x onward), còn các dòng Windows hay Unix thì mình không chắc. Trên thực tế, để thực hiện được cuộc tấn công vào một Linux box là điều rất khó, vì network application nạn nhân chạy trên Linux đó còn phải set IP_RECVERR option cho INET socket mà nó sử dụng. Mà điều này tùy thuộc vào từng application, chứ không phải tùy thuộc vào Linux kernel nữa, bởi vì kernel bản thân nó không bao giờ tự nhiên đụng đến option này. VD: Linux openSSH không set option này (và hiển nhiên không bị tấn công).

darkwizard136 wrote:
Mình có dùng tcmpdump và wireshark để theo dõi connection. Khi connection bị reset thì sẽ có một gói tin tương tự như sau:
Code:
22:21:03.380717 10.0.0.1.3270 > 192.168.0.1.80: R [tcp sum ok] 4174694923:4174694923(0) win 0 (ttl 118, id 23180)


Mình nghĩ có thể sequence number của ICMP không phù hợp nhưng mình chưa tìm ra sequence number như thế nào để phù hợp.  


Hi, hôm nay mới thấy topic này, cũng khá thú vị.

seq trong unreach ICMP phải nằm giữa snd_una và snd_nxt trong tcp socket của bên bị tấn công, vì một lí do hiển nhiên rằng đây là một unreach ICMP.

Thân mến.
 
Go to Page:  First Page Page 1 2 3 4 6 7 8 Page 9 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|