<![CDATA[Latest posts for the topic "MAC, Encrypt và Compress. Sử dụng thế nào cho đúng"]]> /hvaonline/posts/list/8.html JForum - http://www.jforum.net MAC, Encrypt và Compress. Sử dụng thế nào cho đúng MAC - Message Authentication Code. Quá trình tạo một thông điệp xác thực cho thông tin, bảo vệ tính toàn vẹn của thông tin Encrypt - Quá trình mã hoá thông tin Compress - Quá trình nén thông tin ]]> /hvaonline/posts/list/44603.html#275040 /hvaonline/posts/list/44603.html#275040 GMT MAC, Encrypt và Compress. Sử dụng thế nào cho đúng

K4i wrote:
Những ai quan tâm đến mật mã đều biết đến những cặp khái niệm sau: - MAC and Encrypt: Encrypt first, MAC the ciphertext -1 [1]http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html - Compress and Encrypt: Compress first, then Encrypt Vậy nếu kết hợp 3 cái này với nhau thì thứ tự thế nào? Liệu sẽ là: Compress > Encrypt > MAC. Đây đã phải là ý tưởng hợp lý hay chưa? Mời mọi người thảo luận nhân dịp nghỉ lễ ;) PS: Ghi chú một chút MAC - Message Authentication Code. Quá trình tạo một thông điệp xác thực cho thông tin, bảo vệ tính toàn vẹn của thông tin Encrypt - Quá trình mã hoá thông tin Compress - Quá trình nén thông tin  
tớ đồng ý với ý kiến của bạn, việc đó khiến bạn có lợi thế cho một chế độ mã hóa chứng thực như GCM hơn CTR + HMAC.... như hiện nay vẫn có 1 số nơi sử dụng AES-CBC. Làm cho các thiết lập mặc định của "EncryptThisStuff ()" gọi là AES-GCM là đơn giản hơn làm cho nó phun ra một mã hóa hơn một MAC. Điều này thậm chí còn đúng hơn về giải mã bên IMO. Có những điều đơn giản để sử dụng đúng sẽ đi một chặng đường dài để cải thiện an ninh tổng thể. Ưu điểm thứ hai của mã hóa chứng thực là nó dễ dàng hơn để quản lý một dòng dữ liệu đó là quá lớn để thoải mái phù hợp trong bộ nhớ. Tôi đã viết một CTR + giải pháp HMAC cho iOS, và bộ đệm đọc trước yêu cầu quản lý các HMAC nối thực sự những điều phức tạp. Mặc dù vậy, CTR + HMAC là tốt nhất bạn có thể nhận được trên iOS (và CBC + HMAC là tốt nhất bạn có thể nhận được trên máy Mac), vì vậy tôi không có nhiều sự lựa chọn ý kiến này đã đc đưa ra thảo luận rồi nhưng vẫn còn nhiều tranh cái như : muốn phổ biến rộng rãi trên toàn thể các máy tính như GCM chỉ được mặc định, ngay cả khi nó là phức tạp hơn và do đó ít chứng minh, chứ không phải là đã CBC được mặc định như hiện nay, với HMAC như là một thể dục cho người đọc họ đọc xong chẳng hiểu ứng dụng nó thế nào hết :D hiện nay chúng ta vẫn thường hay lưu chủ yếu là các file word hay pdf .... Nếu không nó có sự thay đổi nội dung rõ ràng của tập tin mà không thay đổi signatur. Như đã được chứng minh cho các loại tập tin trên với MD5/SHA1 tổng kiểm tra. Đó là lý do tại sao chúng tôi có các kích thước tập tin và hai loại tổng kiểm tra trong cây cảng, phải không? Bây giờ tôi hiểu rằng một khối mã hóa và HMAC là khác nhau từ một tập tin và một tổng kiểm tra, nhưng vẫn có vẻ là một số song song. nói như trên giờ nói về cấu trúc của các tập tin PDF đã làm cho nó có thể sử dụng một cặp gần như tùy ý va chạm văn bản để tạo ra hai tập tin đụng độ mà trả lại tuy nhiên bạn thích - nhưng điều này chỉ đơn thuần là chuyển đổi "một vụ va chạm" để "tấn công - chọn va chạm ", không làm cho nó có thể tìm thấy va chạm ở nơi đầu tiên ... và ngay cả khi bạn có thể tìm thấy một vụ va chạm trong một * băm *, việc tìm kiếm một vụ va chạm trong tương ứng * HMAC * là một vấn đề khó khăn hơn nhiều. Như thế nào cho cây FreeBSD cổng hoạt động: Chúng tôi đã thêm SHA256 băm vì MD5 đã bị hỏng. Kích thước tập tin là hiện tại vì làm cho nó có thể nhận ra distfiles cắt ngắn và tiếp tục lấy. hiện nay cái này đúng là rất hay nhưng nó chưa đc phổ biết số % phổ biến trên các máy tính không nhiều nhưng đa phần hiện nay ng ta muốn viết + tạo ra những ngôn ngữ mã hoá riêng cho mình thanks! mod K4i :D ]]> /hvaonline/posts/list/44603.html#275106 /hvaonline/posts/list/44603.html#275106 GMT MAC, Encrypt và Compress. Sử dụng thế nào cho đúng /hvaonline/posts/list/44603.html#275177 /hvaonline/posts/list/44603.html#275177 GMT