Messages posted by: StarGhost

SSL/TLS phổ biến đến nỗi có quá nhiều tài liệu giới thiệu, mô tả, giải thích, thêm bớt, bắt bẻ, chê bai, tôn thờ, sùng bái, cũng như... hướng dẫn. Thay vì đọc một quyển sách, nên chăng đọc nhiều quyển sách và nhiều tài liệu để biết cái gì mới là hay, cái gì mới là dở. Chẳng phải như thế mới gọi là nghiên cứu? Nếu không thì thôi cũng đành mang tiếng "quăng bom" vậy.

Nếu home folder đã bị mã hoá thì việc reset password có thể sẽ dẫn đến không thể giải mã và không thể truy cập được home folder. Ngoài ra, bạn có thể cấu hình bootloader để loại bỏ hoặc đặt password cho tính năng recovery. Không ai nói chế độ mặc định của một hệ điều hành miễn phí nhất thiết phải an toàn.

Địa chỉ MAC của "mình"? Mình ở đây là cái gì? Có những cái "mình" ISP có thể biết được, nhưng cũng có những cái "mình" ISP không thể biết được. Còn trong hầu hết các trường hợp thì Webmaster không biết được địa chỉ MAC của "mình".

Câu trả lời nằm ở đây:
http://en.wikipedia.org/wiki/IEEE_754-1985#Rounding_floating-point_numbers
1.=0x3ff

RTFM!

Kinh nghiệm quá hay, đúng lúc mình đang bí không biết làm sao xin việc. Cám ơn mrro rất rất nhiều. À mà mình đọc trên báo thấy người ta tung hô quá trình phỏng vấn của Google dữ lắm, toàn đưa ra mấy câu hỏi đánh đố. Hoá ra báo chí vẫn là báo chí.

Bạn nên bắt đầu từ đây: http://en.wikipedia.org/wiki/Cloud_computing

Mình tự hỏi phải chăng qui định của HVA là không được đăng tên công ty tuyển dụng cũng như phương thức liên lạc hành chính của công ty đó trong mục tuyển dụng này?

p/s: 7USD/ngày đấy, các bạn không nhanh chân là mình xí hết chỗ. smilie

@van7hu: mấy quyển đó mình đọc hồi lâu lâu rồi, và cũng không phải để nghiên cứu gì. Mình đọc chơi chơi thôi. Hiện tại mình đang tập chơi game, đủ các loại game, ngoài ra thì không làm gì khác. smilie

Một tài liệu khoa học thuần tuý có rất ít gạch đầu dòng. Và đây là tài liệu kĩ thuật, nên không cần thiết phải thêm mấy cái lịch sử này kia. Ngoài ra, nên cân nhắc khi giới thiệu các khái niệm, vì nếu khái niệm được giới thiệu ra nhưng không được dùng đến trong tài liệu, thì sẽ là thừa thãi và lan man.

Xem mục ambiguity example trong http://en.wikipedia.org/wiki/Sliding_window_protocol

@WinDak: không có tập gì gọi là tập plaintext+randombit, bởi vì randombit và sự tạo thành nó nằm trong internal operation của encryption function, và input của encryption function chỉ là plaintext, chứ không phải plaintext+randombit. Thậm chí, tính bí mật của giá trị randombit này còn quyết định độ an toàn của thuật toán, thế nên không thể bao gồm nó vào trong plaintext space được. Ngược lại, output của encryption function thì lại là ciphertext với yếu tố random (ví dụ ciphertext+randombit).

WinDak wrote:

"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)

À vấn đề này lại quay lại chuyện dùng khoá nắn trong thuật toán mã hoá mà alice đưa ra. Đây đúng là định nghĩa mà người ta thường dùng cho block cipher, và theo định nghĩa này thì đúng là theo bạn nói block cipher là bijective function. Lý do người ta không bao gồm probabilistic encryption vào trong định nghĩa này thì mình đã nói ở trên. 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.

@alice: về vấn đề cryptanalysis thì chắc là phải đợi nghiên cứu một hồi thì mới dám thảo luận, nhất là khi kĩ năng chuyên môn không có. Nhưng vì lâu lâu mới có thảo luận hay nên mình cũng sẽ cố gắng xem sao. smilie

@WinDak: theo mình biết thì chưa có block cipher nào như vậy. 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ông. Thuật toán mã hoá ở trên đã manh nha xuất hiện suy nghĩ probabilistic encryption, mặc dù có vẻ chưa thành công lắm.

Trong probabilistic encryption, bạn không có thêm cái gì vào plaintext hết, plaintext là những gì bạn đọc hiểu, chứ bạn không thêm yếu tố ngẫu nhiên nào vào nó. 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. Bạn nên coi encryption function là một oracle thì sẽ thấy tính probabilistic của nó.

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

@WinDak: có lẽ bạn đòi hỏi quá cao nếu như cái gì cũng phải có giá trị thực tế, đặc biệt khi đụng đến các định nghĩa vốn cần phải tổng quát hoá để phục vụ cho công tác nghiên cứu. Probabilistic encryption thì bạn cứ tìm hiểu sẽ biết ứng dụng thực tế của nó là thế nào.

Việc D(E(P)) != P có được lợi hay không thì còn tuỳ vào hoàn cảnh cụ thể. Bản thân mình chưa nghĩ ra hoàn cảnh nào cụ thể (ngoài oblivious transfer) nhưng mình cũng không vì thế mà dám chắc rằng nó sẽ không có lợi gì.

@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.

WinDak wrote:

1. 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 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ộ.

2. 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.

3. Ở 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.

Mình mượn tạm công sức của mrro smilie

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.

@mrro: mình xin có ý kiến về hai thắc mắc rất thú vị của bạn:
1. Mình cho rằng lý do các thuật toán mã hoá cụm trước đây không bao gồm chế độ hoạt động vào trong thiết kế của chúng là vì:
- Định nghĩa thường thấy của thuật toán mã hoá là E(K,P) = C, trong đó K là khoá bí mật, P là bản rõ, C là bản mã. Việc sử dụng một định nghĩa thuần tuý rất quan trọng không những trong giao tiếp trao đổi giữa các khoa học gia, mà còn trong việc mô hình hoá một cách toán học các thuật toán mã hoá, ví dụ như liên quan đến key-space, ciphertext-space, ánh xạ, v.v...
- Việc chia tách rõ rệt các chức năng làm trong sáng hơn quá trình mã hoá, dẫn đến dễ dàng tìm hiểu, phân tích và chứng minh các tính năng liên quan đến thuật toán.
- Việc chia tách rõ rệt các chức năng làm tổng quát hoá thuật toán mã hoá, khiến cho nó có thể được dùng trong nhiều trường hợp hơn.
- Và chắc là còn các lí do khác mà mình chưa để ý tới. smilie

2. Theo như mình hiểu thì có lẽ khoá nắn ở đây có khả năng hoạt động giống như một IV trong các chế độ hoạt động như CBC hay CFB. Tuy nhiên, để phân tích về độ an toàn của nó thì có lẽ là khó khăn hơn nhiều, vì việc sử dụng nó đã được trộn lẫn vào trong quá trình mã hoá. Và mình có cảm tưởng làm như vậy giống như kiểu "security by obscurity".

@Alice: cám ơn bài viết của bạn. Mình không làm về crypto nhưng cũng có một chút hứng thú, vài hôm nữa đọc xong bài viết này sẽ vào thảo luận.

Thân mến.

Có lẽ quyết định vị trí như thế nào và thu nhập ra sao không phải là cái bằng, mà là mớ kiến thức trong đầu. Bạn biết chút về SQL và C# thì nếu kiếm cơm bằng 2 cái này may ra bạn kiếm được chút. Còn về bảo mật mạng, thì mình cho rằng bạn không có nhiều hi vọng, vì một khoá học như thế này chỉ có giá trị định hướng chứ không có giá trị cung cấp kiến thức. Ở ta nếu bạn muốn nghiêm túc theo ngành bảo mật (để có một vị trí và thu nhập tốt), thì có lẽ là phải tự học và nghiên cứu hoàn toàn.

@panfider: vậy theo bạn trên thế giới có bao nhiêu nước sản xuất trình biên dịch, bao nhiêu nước sản xuất hệ điều hành? Bạn đóng góp bằng cách ngồi mất công làm những cái người ta đã làm rồi, và có lẽ là khó có thể làm hay hơn được, thì đóng góp đó mang lại lợi ích gì ngoài việc chứng tỏ là mình cũng có thể bắt chước làm được cái này cái kia. Cái danh hão đó căn bản không có chút giá trị thực tế nào hết.

Mình đưa ra đây một số gợi ý:
- Các kiểu tấn công và phòng thủ liên quan đến Denial of Service (DoS).
- phương thức hoạt động và bảo mật trong peer-to-peer routing.
- bảo mật hệ thống wireless (xác thực, mã hoá, wardriving, v.v...)
- intrusion detection system (IDS) agents trong mạng máy tính.
- bảo mật trong anonymity network (ví dụ Tor)

Những đề tài này nếu khai thác triệt để về khía cạnh lý thuyết thì có lẽ sẽ rất lý thú, còn thực hành chỉ là hình thức. Về mặt thực tiễn, bạn có thể thử tìm hiểu các chuẩn thiết kế hệ thống mạng (ví dụ Cisco layered hierarchy), và phân tích điểm yếu mạnh của chúng trong môi trường enterprise network, mình nghĩ cũng là một đề tài hay.

Thân mến.

Có lẽ bạn nên liệt kê các thể loại kiến thức mà bạn có (toán, chuyên ngành, lập trình, v.v...) để mọi người biết mà góp ý. Ngoài ra, bạn cũng cần nêu rõ là bạn muốn làm thiên về lý thuyết hay thực hành. Còn nữa, đề tài còn phải phụ thuộc vào sự đồng ý của thầy, vậy tại sao bạn không hỏi xin đề tài trực tiếp từ thầy?

Thân mến.

@panfider: hình như bạn hiểu nhầm. VN mình không có ai viết ftpd có lẽ không phải là vì dở, không biết viết, mà căn bản là không tìm ra mục đích để viết. Viết để làm gì khi mà ftpd đầy rẫy ra, chả lẽ để chứng tỏ là mình biết viết ftpd? Tại sao không dành thời gian nghĩ/thiết kế cái gì mới rồi bắt tay vào thực hiện?

@panfider: bạn viết ftpd, named để làm gì? Sao phí thời gian vậy?

Tạo số lượng lớn trong thời gian ngắn thì nên dùng C để đạt được tốc độ cần thiết.

"Vấn đề xác thực" là cái gì? Là vấn đề liên quan đến việc xác thực, hay phương pháp xác thực? Xác thực ở đây là xác thực cái gì? http://en.wikipedia.org/wiki/Authentication có cung cấp một số các thông tin và từ khóa hữu ích cho việc bắt đầu tìm hiểu.

Wow, mrro có paper accepted ở Oakland (world best security conference). Không còn gì để nói, xin chúc mừng. Clap clap.

Ar0 wrote:

Ăn nghe toàn về "an toàn mạng" hoài cũng ngán, chính xác thêm xí nữa thì dùng từ "an toàn thông tin" cho chính xác, nó rộng hơn an toàn mạng rất nhiều.

Chính xác hơn? Nghĩa là "an toàn mạng" hay "an ninh mạng" thì không chính xác?
Rộng hơn? Rộng hơn để làm gì nếu cái người ta muốn tập trung vào chỉ là "an ninh mạng" hay "an toàn mạng"?

@Ky0: cái định nghĩa "an ninh mạng" bạn xem ở đâu vậy? Mình cũng không biết có cái định nghĩa này. smilie

@debutant: bản thân cái file đó không thể tự khoá được, chỉ có cái chương trình dùng để đọc nó thì không cho người dùng truy cập sau 48h. Nếu chương trình đó (hoặc một chương trình đọc pdf nào khác) không muốn làm thế thì dù cái file đó có được thiết kế thế nào thì vẫn không ngăn chặn được việc truy cập.

Ngày nay PDF đã trở thành một chuẩn mở nên việc cho đọc mà chống in/ấn này kia là điều bất khả thi.

Mục đích của việc mã hoá là để chống xem thông tin, chứ không phải là để chống chỉnh sửa thông tin. Vì vậy dù mã hoá kiểu gì chăng nữa thì căn bản là không có tác dụng.