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: 5 ]
 
@eicar: wow, lần đầu tiên mình biết có người trên HVA nghiên cứu về crypto ở mức độ lý thuyết. Bạn có thể giới thiệu qua về lĩnh vực nghiên cứu của bạn được không? Nếu được bạn có thể PM mình để tránh làm loãng chủ đề. Mình rất cám ơn.

Thân mến.
Mình đoán có lẽ là họ không bị dính vào căn bệnh ung thư của xã hội, a.k.a. Facebook. smilie Mình mà không bị facebooked, thì mình cũng giỏi như ai lol.
@quangdau: những câu hỏi của bạn là các khái niệm cơ bản, bạn có thể tìm được ở nhiều nơi. Trong blog của mrro đã có bạn đưa link rồi đấy. Mình thấy sẽ thú vị và ích lợi với bản thân bạn hơn nếu bạn tự tìm hiểu, rồi đưa ra thảo luận các vấn đề cụ thể mà bạn thấy lí thú, hoặc khó hiểu, sau khi đã nắm vững các kiến thức cơ bản. Mình tin rằng trong quá trình thảo luận thế nào cũng có lúc các khái niệm được nhắc đến một cách rõ ràng. Lý thuyết mật mã không phải là ngành học chơi cho vui, mà muốn hiểu hoặc/và làm nên được cái gì đó thì phải mất rất nhiều công sức.
Đào tạo tốt thì nhiều nước có, cả Mỹ Âu Á đều có. Còn tốt nhất thì chắc là ở Mỹ. Ngoài ra Mỹ cũng là một môi trường năng động, đặc biệt thích hợp với những bạn có xu hướng industry. Nếu bạn đi được thì Mỹ là tốt nhất, với điều kiện trường bạn theo học phải là trường tốt, ví dụ top 50 chẳng hạn.
@jcisio: hì hì, bạn tưởng tượng thế là nhầm ý mình rồi, nên mới cho rằng nguy hiểm. Câu trên của bạn mình thêm một chữ "thiếu", thành như sau:
PS: cho rằng một hệ thống dùng hash, thí dụ MD5, cũng thiếu an toàn như một hệ thống khác dùng key strenngthening (cũng với MD5 luôn) thì có nguy hiểm hay không?  

Một khi mình đã giả định rằng hàm hash hoạt động nhanh, tức là mình đã không còn tính phụ thuộc vào nó như là một miếng vá security. Như vậy có nghĩa là mình sẽ tính đến việc sử dụng các giải pháp khác thay thế/bọc lót để chống password cracking. Như vậy thì có nguy hiểm chăng?

Như đã nói ở trên, mình công nhận là trong hầu hết trường hợp thì việc áp dụng vẫn cho hiệu quả. Tuy nhiên, mình vẫn bảo lưu 2 quan điểm rằng kĩ thuật này không có "stand the test of time", và không nên dùng với hệ thống quan trọng và cần sự ổn định lâu dài. Bạn thử tưởng tượng attacker nắm trong tay hệ thống tính toán gồm vài chục nghìn máy tính thì sao?
@jcisio: hì hì, bạn vẫn chưa chỉ ra được là cái ngộ nhận của mình nguy hiểm ra sao? Bạn có biết mình sẽ làm thế nào với cái ngộ nhận đó chưa mà phán rằng nó nguy hiểm? Về WPA, cái việc sử dụng phương pháp key strengthening không bắt buộc trong protocol bạn ạ, mà nó là implementation specific. Và ngay kể cả khi người ta implement nó rồi, thì người ta cũng vẫn phải nhấn mạnh vấn đề low entropy của password. Lí do đơn giản là vì đây chỉ là giải pháp tạm thời, nó căn bản không phải là phương pháp có thể "stand the test of time". Ngay cả đến những thứ như RSA cryptosystem còn liên tục phải tăng key size (khi mà độ phức tạp tấn công là exponential increase), thì với cái phương pháp mà có độ phức tạp cho việc tấn công theo kiểu linear increase thế này, căn bản không thể dùng được với những hệ thống lớn, cần sự ổn định lâu dài.

Tuy nhiên, có thể bạn đúng là nó có thể được áp dụng ở các trường hợp có mức độ critical về security thấp hơn. Mình nói có thể vì căn bản bạn chưa đưa ra được một thống kê hoặc phân tích khoa học về mức độ security liên quan đến phương pháp này. Bạn nói nếu DDoS thì thà DDoS trang search hơn là DDoS trang đăng nhập, nhưng bạn phát biểu thế thì quá ngây thơ rồi. Mình không nghĩ một administrator nào lại có thể nói rằng: à hệ thống của thằng kia DDoS dễ hơn kìa, sao mày không tấn công nó đi, tấn công tao làm gì.

p/s: Vì mình không làm về kĩ thuật nhiều, nên mình cũng xin hỏi các bạn là thời gian server bỏ ra để tính toán xác thực là 100ms thì gọi là nhiều hay ít? Với một hệ thống lớn cỡ nào thì chấp nhận được?

jcisio wrote:
@eicar: 100 ms / 1 us = 100.000 là hiển nhiên rồi, chứng minh gì nữa?

@SG: mình không có tham gia tranh cãi, mình chỉ bảo câu bạn nói (được trích) là sai thôi, đó là một ngộ nhận rất nguy hiểm.

Việc xây dựng một hàm hash đòi hỏi thời gian tính toán "lâu" là rất quan trọng. 2 trong 3 CMS phổ biến nhất (Drupal, Joomla, WP) đã dùng phpass rồi http://www.openwall.com/phpass/ 


Haha, bạn jcisio nói đúng, mình đã ngộ nhận, còn nguy hiểm như thế nào thì mình còn chưa rõ. Mình ngộ nhận như vậy, căn bản là vì mình luôn giả sử rằng người ta thiết kể các hash function với một thuộc tính bất di bất dịch: càng nhanh càng tốt. Chính vì vậy mình luôn mặc định rằng sự biến thiên về độ phức tạp là không đáng kể. Quan điểm của mình là cái gì được thiết kế ra và test kĩ lưỡng để dùng với mục đích này thì chỉ nên dùng nó với mục đích đó, và không nên trao cho nó trọng trách khác, vì có thể gây ra nhiều phiền toái bất ngờ trong tương lai.

Còn bạn cho nó hash n lần (n=1000) thì mình công nhận là gây khó khăn cho quá trình brute-force. Tuy nhiên, mình cho rằng đây là một hạ sách. Vì sao? Security bao giờ cũng có cái giá của nó. Tuy nhiên, khi thay đổi một hệ thống để tăng cường security cho một điểm yếu, người ta cố gắng làm sao để chi phí càng ít càng tốt, và security được tăng cường càng nhiều càng tốt, đồng thời không tạo ra điểm yếu ở chỗ khác.

Với việc hash 1000 lần, hoặc thiết kế một hàm hash khác có độ phức tạp hơn 1000 lần hàm hash cũ, bạn làm cho nỗ lực brute-force tăng thêm 1000 lần, nhưng đồng thời cũng làm cho chí phí trong quá trình xác thực của hệ thống tăng thêm 1000 lần. Nói cách khác, security và cost có cùng tỉ lệ.

Giả sử kẻ tấn công có khả năng brute-force password khi bạn dùng hàm hash cũ. Bây giờ bạn có khả năng tăng 1000 lần chi phí cho việc xác thực, phải chăng attacker không có khả năng tăng 1000 lần chi phí cho việc tấn công, thậm chí là tệ hơn nữa nếu cái mớ chi phí đó không hoàn toàn do attacker bỏ ra? Ngoài ra, việc tăng cường độ phức tạp tính toán trong quá trình xác thực còn gây ra một vấn đề, đó là DoS, khi mà thời gian xác thực mất tới 100ms.

Thú thực mình không biết là phương pháp này đã được cài đặt vào các sản phẩm nào, và bao nhiều phần trăm các hệ thống trên thế giới sử dụng các sản phẩm đó, và bao nhiêu phần trăm trong số đó enable chức năng này. Nếu bạn (hoặc ai đó tham gia topic) có thống kê thì có thể đưa ra để cùng thảo luận, vì có thể phương pháp này còn có ưu điểm khác mà mình chưa nhận ra.

jcisio wrote:
Solution tôi đưa vài hôm trước rồi. Nhưng chờ code để ăn sẵn thì không có đâu! Trừ khi có vài người code thử trước. Còn crazyboy thì tôi không biết là ai (xin lỗi), nên tôi không biết là sẽ có solution không. 

Chúc mừng bạn jcisio đã tìm ra được mật khẩu. Mình cũng đành chờ giải đáp của bạn thôi, vì mình cũng không làm được. Còn nếu chẳng may bạn không bố thí đoạn code đó thì mình đành nhịn ăn vậy. smilie Nhưng bạn cũng phải cân nhắc cho kĩ vì có thể mình sẽ chôm ý tưởng của bạn để viết paper đấy.
Bạn eicar làm mình giật mình vì nêu lên một loạt các nhận định về HVA và conmale. Đề nghị bạn nêu ra những dẫn chứng cụ thể, vì có một lượng lớn thành viên (trong đó có mình) đang dựa trên những bài viết của conmale để phấn đấu.

Mình không rõ conmale có định kiến gì, nhưng qua bài viết của bạn thì đã thấy cái định kiến của bạn rồi. Mình đoán bạn học nếu không phải là pure maths thì cũng là theoretical computer science. Chính vì vậy khi nhắc đến những thứ khoa học như TCP/IP, DoS (computer networking), Unix/Linux (operating systems) thì bạn đã cho là tiểu tiết/tricks, chứ chưa nói đến những thứ như CCNP, Web, hacking...

Bạn đưa ra lời khuyên thì nên để ý xem người bạn khuyên đang đứng ở đâu, rồi dựa vào đó đưa ra lời khuyên phù hợp. Nếu bạn chưa đứng ở vị trí đó hoặc các vị trí xung quanh bao giờ thì nhiều khả năng là không đủ kinh nghiệm để đưa ra lời khuyên, và dễ dẫn đến định kiến. Mình nói thật là có một sự khác biệt rất lớn giữa bạn và chủ topic, nên bạn cần tỉnh táo.
@myquartz: à mình không có ý định tranh cãi nữa, vì lí do gì thì mình đã nói ở trên rồi. Dù có tranh cãi kiểu gì cũng không thể đến "kỳ cùng" được.
@myquartz, jcisio: đứng về mặt thực tiễn mà nói, các bạn không có sai. Khi một phần mềm bị phát hiện lỗ hổng, người ta thường vá nó chứ không ai vứt đi rồi redesign lại. Khi một phương pháp crypto có lỗ hổng, các bạn cũng có thể vá nó như cách các bạn đưa ra, nếu việc thay đổi hoàn toàn là quá khó khăn.

Nhưng phải cẩn thận, bản vá cũng có thể có lỗ hổng của chính nó, HTTP digest auth là một ví dụ. Bạn myquartz đọc kĩ security considerations của nó sẽ hiểu cái trade-off của nó là gì. Mình thì không phải dân kĩ thuật, nhưng mà HTTP digest auth thì mình cũng biết được từ khá lâu, chỉ là không rõ nó phổ biến ra sao thôi.

Mình nghĩ là vì ở các góc nhìn khác nhau nên căn bản là không thể đưa đến được sự thống nhất tư tưởng. Các phương pháp chúng ta đưa ra ở đây có lẽ đều đạt mục tiêu chống pass the hash như chủ topic đưa ra.

Thân mến.
@myquartz: Ừ bạn có thể hash cái mật khẩu đó, nhưng nếu vậy attacker cũng không cần biết cái mật khẩu đó là gì, chỉ cần biết cái giá trị hash thôi là đủ để xác thực thành công rồi. Nói cách khác, với cái kiểu protocol của bạn, giả sử attacker chẳng may truy cập được file password của server thì hoàn toàn có thể login vào bằng bất cứ username nào trong file password đó mà không cần tốn công sức gì cả.

Còn chuyện brute-force mật khẩu không có phụ thuộc vào sức mạnh của hàm hash (đã gọi là brute-force mà), mà chỉ phụ thuộc vào độ phức tạp của mật khẩu. Tuy nhiên, nếu những người thiết kế các giao thức authentication mà luôn giả định rằng user sẽ đặt mật khẩu đủ mạnh thì người ta còn cần đến những cái key dài dài làm gì hả bạn?
@myquartz: protocol của bạn chỉ đảm bảo là password không truyền qua môi trường Internet dưới dạng plaintext, nhưng nó lại bị lưu trong server dưới dạng plaintext. Ngoài ra, protocol này còn cho phép nghe lén sau đó brute-force để tìm ra password. Trên thực tế, lời khuyên của WinDak là hoàn toàn chính xác, trừ phi bạn là một nhà nghiên cứu về crypto có kinh nghiệm, thì mới nên tự tin về protocol của mình.

eicar wrote:

Ý sau thì anh hiểu nhầm cái em muốn nói, anh mrro muốn mô tả một cái attack đối với scheme sử dụng OTP. Ý em là hiện nay các kiểu xác định attack như vậy không phải là một điều gì khó khăn, vì đã có các phương pháp hình thức rất tốt để làm điều này. Về mặt lý thuyết, thì bài toán kiểm tra một giao thức bất kỳ là NP-complete, tuy nhiên trong thực tế đối với phần lớn các giao thức hiện tại (em không rõ có phải tất cả hay không) thì các thuật toán kiểm tra đều rất hiệu quả.

Điều này cũng giống như việc phát hiện virus, trong trường hợp tổng quát, bài toán kiểm tra sự tồn tại của virus cũng là NP-complete, tuy vậy thực tế vẫn tồn tại các chương trình diệt virus rất tốt. Nhưng về mặt lý thuyết, vẫn có thể thiết kế các virus mà cực kỳ khó phát hiện (em chưa biết trong thực tế điều này đã được ứng dụng để viết virus phá hoại hay chưa), theo nghĩa độ phức tạp tính toán mà không phải theo nghĩa nó sử dụng các tricks khó khăn về mặt kỹ thuật. 


Về crypto thì may ra mình còn quờ quạng, chứ còn về complexity theory và formal methods thì mù tịt, nên có lẽ là không hiểu được ý của bạn. smilie Mấy cái phương pháp kiểm tra protocols mà bạn đề cập có phải đại loại như Dolev-Yao?
Mấy bạn kể cũng rảnh thật. Network RTT nó noise còn nhiều hơn cả thời gian check password, các bạn mà tìm ra được thì đúng là tài. Hoặc giả cái con server chạy siêu rùa thì bó chiếu rồi. smilie
Bạn eicar thân mến, câu hỏi của bạn rất hay. Tuy nhiên bạn còn chưa đọc kĩ câu của mình, mình nói là "MITM hoặc/và impersonation". Ngay cả trao đổi khoá lượng tử cũng không thể chống được impersonation, một khi không có secure authentication. Còn MITM thì không phải lúc nào cũng xảy ra, như như ví dụ mình đã nêu ra ở trên, hoặc ví dụ của bạn, là không khả thi.

Lí do tại sao có khẳng định của mình thực ra rất là hiển nhiên thôi, và không cần phải kiểm trả một giao thức nào để dẫn đến NP-complete. Giải thích rất đơn giản: authentication của một party hoạt động dựa vào những gì mà party đó sở hữu. Trong trường hợp no authentication/weak authentication, attacker (thường là PPT) hoàn toàn có thể thu thập hoặc giả lập các sở hữu đó, và tiến hành impersonation.

Đính chính: viết xong bài này mình mới nghía qua xem trao đổi khoá lượng tử nó là cái gì. Tuy nhiên mình đọc thấy nó chỉ chống eavesdropping, chứ đâu có chống được MITM. Về cơ bản, nếu impersonation có thể thực hiện được hai chiều thì nó hiển nhiên dẫn đến MITM.
Ở đây mình thấy các bạn từ đầu đến giờ luôn đề cập đến việc đọc (đi và lại) cho đến khi hiểu, nhưng lại không có bàn đến chuyện thế nào là hiểu, hiểu ở mức độ nào. Nếu không xác định được mức độ hiểu mình cần phải có thì sẽ còn phải chạy đi chạy lại hoài. Mời các bạn cho ý kiến về vấn đề này.
mrro thân mến, one-time pad đúng là có commutative, nhưng mà nếu như biết ciphertext và plaintext thì sẽ suy ra được key, thế nên nó căn bản khó có thể áp dụng trong trường hợp này được. Trong khi đó thuật toán như bạn WinDak đề cập thì dựa vào vấn đề discrete log để ngăn việc tìm key.

@angel-pc: ở đây đang nói đến vấn đề xác thực, mình không hiểu captchar thì dùng để xác thực thế nào?

WinDak wrote:

A contact đến B sau khi authenticate đến bước trao đổi khoá, C ở giữa và thay vì gửi hòm đến B thì C khoá bằng khoá của C và giả làm B. C có thể không contact luôn đến B, hoặc giả làm A contact đến B. Như vậy sau 2 quá trình trao đổi khoá trong hòm, C có khoá A<->C và C<->B, C có thể thoải mái forward message từ A đến B như thật, trong khi 2 người này hoàn toàn không biết có người ở giữa. Không biết cái này là impersonation hay là MITM ? xin StarGhost cho mở mang tầm mắt.
 

Trước hết mình cần làm rõ quan điểm của mình về sự khác nhau giữa impersonation và MITM. Impersonation xảy ra khi attacker có thể giả dạng một end-point để giao tiếp với end-point còn lại. MITM xảy ra khi attacker có thể đứng giữa và cùng một lúc giả dạng mỗi end-point và giao tiếp với end-point kia.

Còn cái attack kia của bạn là attack dành cho commutative encryption ở mức độ tổng quát, còn cái chúng ta đang bàn ở đây là khi commutative encryption được sử dụng để truyền password như mô hình của chủ topic.

WinDak wrote:
Trên thực tế thì có thể thêm identity của A và B ở trong hòm thì sẽ không bị trường hợp này. 

Bạn thêm identity bằng cách nào để "không bị trường hợp này"?
Còn mình thì không hiểu cái mục đó sinh ra để làm gì nữa. smilie
@WinDak: bất cứ một kết nối nào (sử dụng bất cứ một loại cryptographic protocol nào) không có secure authentication của ít nhất một end-point thì đều có thể bị MITM hoặc/và impersonation attack. Vì vậy, đối với mô hình trong topic, đòi hỏi về security không nên quá tham vọng, mà chỉ nên dừng lại ở 2 mục tiêu quan trọng: i) không lưu password dưới dạng plaintext và ii) không truyền password dưới dạng plaintext để chống sniffing.

Ngoài ra, bạn WinDak thử mô tả xem tấn công MITM diễn ra như thế nào. Riêng mình thì mình không nghĩ là có thể tấn công MITM, tuy nhiên impersonation thì được.
@radiohead: quá chuẩn.

Mình biết có một ý tưởng như sau: làm một cái hòm có 2 ổ khoá, user sau khi cho password vào hòm sẽ khoá lại bằng ổ của mình, sau đó gửi đến server. Server sau đó khoá cái ổ còn lại và gửi về user. User mở khoá của mình và gửi hòm lại server. Server mở khoá hòm và lấy password, sau đó hash nó và so sánh với giá trị hash trong database.

Để hiện thực hoá cần hai one-to-one mappings f và g (tượng trưng cho 2 ổ khoá) với commutative composition. Ví dụ lý tưởng là commutative encryption. Mình thấy cũng thú vị nếu các bạn thảo luận về những vấn đề liên quan đến giải pháp này.
Mình nghĩ trước khi chọn khoá học, bạn nên tự trả lời những câu hỏi sau: Bạn thích làm gì? Bạn đã biết được những gì? Định hướng nghề nghiệp (tổng quát) của bạn là gì? Bạn đưa câu trả lời lên đây thì may ra có người tư vấn cho.

Các câu hỏi còn lại đáng tiếc mình không có kinh nghiệm gì nên không trả lời được.

heroandtn3 wrote:
Nên tập trung vào việc học ở trường, đó là ưu tiên số 1. Thời gian rảnh thì học thêm Tin.

toán lý hoá thì kì thi học kì vừa rồi của em là 6,25-6-9,5 smilie ( không biết ổn không :-ss)  


Không ổn smilie). Ngày xưa thi HK Toán, Lý, Hoá của mình tổng luôn luôn lớn hơn 27 smilie. Nếu bạn không cải thiện được thì khó thi đỗ ĐH ở Việt Nam, còn sang Úc thì không biết có đú được với người ta không nữa smilie


Đú mạnh ấy chứ. Nói chi 27, có khi 19-20 cũng đủ làm "đại ca" rồi. Quan trọng tư duy tốt là được. Còn về mặt trình bày thì tụi bên Tây phải gọi VN bằng sư phụ.
Thay mặt những người được lợi từ loạt bài viết này (dù chưa biết cụ thể là những ai), chân thành cám ơn công sức hiếm có của mrro trong việc phổ cập cryptography.

Quyển sách mrro giới thiệu mặc dù đơn giản và dễ hiểu, nhưng sẽ cho độc giả cái nhìn cực kỳ bao quát về nền tảng của modern cryptography, điều không thể thiếu đối với những ai muốn học và nghiên cứu chuyên sâu về ngành này. Mình cũng rất khuyến khích các bạn tìm đọc.

Thân mến.
 
Go to Page:  First Page Page 2 4 5 6 Page 7 Last Page

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