Băm nhanh: kết hợp các kỹ thuật khác nhau để xác định các thay đổi trong một tệp?

Tôi muốn tạo một cách nhanh chóng để phát hiện xem một tệp có thể giống nhau hay không. Đối với sự chắc chắn gần như 100%, tôi sẽ sử dụng thuật toán băm hiện có, ví dụ SHA256. Tuy nhiên, các tệp được dự kiến ​​là các tệp video khổng lồ với vài GB, do đó, việc tính toán hàm băm SHA256 có thể mất một thời gian, đặc biệt là qua mạng.

Vì vậy, tôi muốn kết hợp các kỹ thuật khác nhau:

• kích thước tệp: nếu kích thước tệp đã thay đổi, nội dung đã thay đổi (chắc chắn)
• băm đầu / đuôi
• băm ngẫu nhiên

2 cái sau là một phần câu hỏi của tôi:

Tôi đoán là trong tiêu đề có những thứ như:

• tốc độ khung hình (ví dụ Video)
• độ phân giải (ví dụ: Video, Hình ảnh)
• (tệp) chiều dài (ví dụ: trong khung, pixel, v.v.)
• ngày thay đổi cuối cùng (ví dụ: tài liệu Word, không cụ thể là Video)

Tại sao tôi xem xét việc kiểm tra đuôi là:

• MP3 có thông tin thẻ ở đó
• EXIF thêm dữ liệu tùy chỉnh vào cuối nếu tôi đúng

Băm ngẫu nhiên sẽ chọn ví dụ 126 vùng tại các vị trí ngẫu nhiên trong tệp có độ dài cụ thể, ví dụ 64 kB và tạo hàm băm cho chúng. Tất nhiên tôi nhớ các offset để so sánh sau. Tất cả trong tất cả tôi sẽ sử dụng (1 + 126 + 1) * 64 kB dữ liệu cho hàm băm của mình, vì vậy tôi chỉ cần đọc 8 MB thay vì vài GB để có được hàm băm.

Có thể bây giờ đây là câu hỏi Toán học nhiều hơn, nhưng: khả năng phát hiện thay đổi bằng cách sử dụng kết hợp kích thước tệp, đầu, đuôi và dữ liệu ngẫu nhiên để tạo ra tổng băm nhanh này?

Tôi giả định rằng các tập tin luôn luôn là tập tin hợp pháp. Không có lợi ích trong việc thao tác các byte đơn. Người dùng sẽ sử dụng một công cụ chỉnh sửa video bình thường để thay đổi các tập tin.

CẬP NHẬT : Tôi không chấp nhận câu trả lời này xuất phát từ Crypto.StackExchange. Tôi đồng ý rằng đề xuất của tôi không phải là mật mã và không có ý định bảo mật. Tôi cũng đồng ý rằng CRCing một tệp là nhanh, nhưng trong trường hợp của tôi, tôi thực sự cần một hàm băm - tôi sẽ giải thích lý do:

• Ứng dụng của tôi dự kiến ​​sẽ lưu dấu trang trong video. Cơ sở dữ liệu của tôi dự kiến ​​sẽ lưu băm video và dấu trang.
• Người dùng đôi khi di chuyển hoặc đổi tên tập tin. Chương trình của tôi sẽ nhận thấy rằng một tệp không còn tồn tại, nhưng sẽ không xóa các dấu trang khỏi cơ sở dữ liệu. Thay vào đó, khi cùng một video (vô tình) được phát lại, tôi muốn nhận ra rằng đó (có thể) cùng một tệp.
• Người dùng dự kiến ​​sẽ lưu các tệp trên ổ đĩa mạng (NAS) và truyền phát video. Đó là những kho câm. Tôi không thể cài đặt một thành phần máy chủ. Và chúng có thể khá chậm, vì vậy tôi thực sự không muốn băm đầy đủ. Việc tính toán hàm băm đầy đủ trên tệp 3 GB mất ít nhất 5 phút @ 10 MB / s, bất kể thuật toán băm nhanh như thế nào.
• Nếu người dùng đã chỉnh sửa tệp, bằng cách nào đó tôi hy vọng rằng hàm băm sẽ không khớp nữa, vì nếu không tôi sẽ hiển thị dấu trang sai.

Tôi sẽ ổn với ~ 80% cơ hội có các dấu trang chính xác. Có bao nhiêu phần băm tôi nên đặt cùng nhau và vị trí trong tệp sẽ ở đâu?

Đồng xu của bạn có hai mặt:

1. nếu bạn muốn thực hiện bảo mật, bạn sẽ cần sử dụng hàm băm bảo mật bằng mật mã như SHA256 (mã hóa băm có nghĩa là nhanh, nhưng có xu hướng hơi chậm do các ràng buộc bảo mật),
2. những thứ như CRC chắc chắn nhanh hơn, nhưng sẽ không bao giờ có thể cung cấp cùng một loại bảo mật (đặc biệt là khi chúng ta đang nói về.

Tùy chọn 1: CRC - Thực hiện nhanh chóng với giá bảo mật:

Nếu bạn chỉ sau khi phát hiện các thay đổi, hãy đi kiểm tra thay vì băm. Đó là những gì tổng kiểm tra đã được thực hiện cho: nhanh chóng phát hiện các thay đổi trong tệp hoặc luồng dữ liệu. Nhưng hãy nhớ rằng CRC được thiết kế để ngăn ngừa lỗi truyền, không phải là hành động độc hại!

Thực tế, CRC32 là ứng cử viên rõ ràng nhất (nhưng ngay cả CRC8 phụ gia cũng sẽ thực hiện công việc nếu bạn chỉ muốn phát hiện nếu có gì đó thay đổi và không mong đợi gì khác ngoài CRC.)

Tùy chọn 2: Vượt ra ngoài CRC - Thực hiện khá nhanh trong khi tăng cường phát hiện thay đổi:

Các tùy chọn hợp lệ khác (xem bình luận của @ poncho ) thực sự chỉ đơn giản là kiểm tra dấu thời gian của mod cuối cùng .

Hoặc, bạn kết hợp cả hai (để ngăn chặn tắc nghẽn), bằng cách sử dụng một cái gì đó giống như mã giả này cho thấy:

if(LastMod != knownLastMod) { CreateNewCRCandCompare(FileName, knownCRC) };

Nhưng điều này có cung cấp bất kỳ bảo mật thực sự? Không. Tương tự với trò chơi của bạn

Tại sao tôi xem xét việc kiểm tra đuôi là:
- MP3 có thông tin thẻ ở đó
- EXIF ​​sẽ thêm dữ liệu tùy chỉnh vào cuối nếu tôi đúng

Một lần nữa, nó phụ thuộc vào mức độ bảo mật mà bạn mong đợi. Bạn phải nhận ra rằng một kẻ thù chắc chắn sẽ thao túng tệp để giữ (hoặc sao chép và dán) bất kỳ dữ liệu ID3 và EXIF ​​cũ nào như bất kỳ ai (có quyền truy cập tệp RW phù hợp) có thể sửa đổi điều đó. Tương tự với dấu thời gian Sửa đổi lần cuối, tốc độ khung hình, độ phân giải, ngày thay đổi cuối cùng và thậm chí cả độ dài (tệp). Tùy thuộc vào dữ liệu đó có thể sửa đổi và các dữ liệu khác có thể sửa đổi và có thể được sửa đổi và xóa bởi bất kỳ ai có đủ quyền truy cập tệp - sẽ giới thiệu một lỗ hổng bảo mật.

Nhưng bạn có mong đợi sự bảo mật không? Rốt cuộc, đó là lý do tại sao bạn nghĩ về tất cả điều này ở nơi đầu tiên. Chà, không có cách nào để sử dụng băm bảo mật tiền điện tử

Tùy chọn 3: Băm an toàn bằng mật mã - Thực hiện an toàn ở mức giá:

Nếu bạn mong đợi bảo mật thực sự, bạn sẽ phải dựa vào băm; nói chính xác hơn: băm an toàn bằng mật mã (sử dụng hàm băm không được biết là tạo ra va chạm). Phải mất thời gian (một vài microsec mỗi MB) nhưng nó đáng giá.

2 xu (cá nhân) của tôi:

Cố gắng sống với thực tế là băm tốn thời gian và băm toàn bộ tệp bằng hàm băm bảo mật bằng mật mã . Bởi vì, khi mọi thứ bắt đầu ập đến fan fan, tốt hơn hết là bạn nên chậm lại, thay vì xin lỗi.

EDIT dựa trên EDIT của bạn

Nếu bảo mật mật mã không phải là trọng tâm chính của bạn, bạn có thể xem MD5 hoặc SHA1. Cả MD5 và SHA1 đều bị phá vỡ bằng mật mã bởi vì các va chạm đã được phát hiện, vì mục đích phát hiện thay đổi mà bạn mô tả (đặc biệt là sau EDIT của bạn), khả năng xảy ra va chạm như vậy là đủ tối thiểu.

Nhìn lại mọi thứ (bao gồm cả EDIT của bạn), cá nhân tôi rất có thể sẽ sử dụng MD5, vì nó cung cấp khả năng chống va chạm có thể sử dụng (cho mục đích phát hiện thay đổi) trong khi vẫn đủ nhanh để băm hoàn toàn các tệp nhiều gigabyte.

Nếu điều đó vẫn không làm bạn hài lòng trong một cảm giác “tốc độ” hoặc nếu tài nguyên phần cứng của bạn là thực sự mà hạn chế, bạn phải cố gắng để cân bằng va chạm kháng / thay đổi phát hiện với tốc độ. Ý nghĩa…

Lấy dấu thời gian riêng lẻ, tên tệp riêng lẻ và băm tiêu đề (độ dài phụ thuộc vào loại phương tiện và định dạng tệp được sử dụng) cũng như một đoạn tốt từ giữa và một đoạn đuôi tốt (= cuối tệp). Kết hợp cả 5 và bạn sẽ có thể lọc ra hầu hết

Tôi sẽ ổn với ~ 80% cơ hội có các dấu trang chính xác. Có bao nhiêu phần băm tôi nên đặt cùng nhau và vị trí trong tệp sẽ ở đâu?

Đó là ý kiến ​​cá nhân nhiều hơn, vì nó phụ thuộc vào toàn bộ khối lượng chi tiết (loại phương tiện, định dạng tệp, tài nguyên có sẵn, tỷ lệ phát hiện thay đổi dự kiến, độ tương tự của tệp, v.v.) nên sẽ phải tự cân bằng tùy thuộc vào cá nhân của bạn mong đợi, việc triển khai của bạn và kết quả cục bộ do tắc nghẽn phần cứng và / hoặc phần mềm.

Hãy để tôi cố gắng cung cấp cho bạn một số hướng dẫn tuy nhiên:

Nếu băm tập tin hoàn chỉnh không phải là một lựa chọn vì bất kỳ lý do gì, tôi sẽ - ít nhất là - lấy: tiêu đề (và có thể thêm vài KB), một đoạn tốt từ giữa (ít nhất là kích thước của tiêu đề & co . Phần một) và một đoạn tốt từ phần cuối của tệp (một lần nữa, ít nhất là kích thước của phần tiêu đề & phần.

Càng nhiều tài nguyên bạn có thể đầu tư (hoặc sẵn sàng đầu tư), bạn càng có thể nhận được nhiều khối hơn và / hoặc những khối đó càng lớn. Nếu bạn nghĩ rằng tài nguyên / cảm nhận / bất cứ điều gì của bạn vẫn cung cấp nhiều chỗ hơn, hãy tăng kích thước của khối bạn băm và / hoặc tăng số lượng khối bạn băm.

Việc tăng số lượng khối là dễ dàng: vì tất cả những gì bạn cần làm là chăm sóc một phân phối bằng nhau (bằng cách chia kích thước tệp cho phù hợp, dẫn đến các khối có cùng kích thước bạn trích xuất từ ​​các phần cách đều nhau trên toàn bộ chiều dài tệp).

Và nếu bạn đang tự hỏi mình Tại sao lại phân bổ đều và không phải là các vị trí chunk ngẫu nhiên? Hãy, tôi chỉ lưu ý rằng việc chọn các vị trí chunk ngẫu nhiên có thể thực sự khiến các nỗ lực phát hiện thay đổi của bạn bị vô hiệu vì nó có nguy cơ bỏ qua một số phương tiện quan trọng trong đó bạn thường sẽ phát hiện các cơ hội mà bạn đang nhắm đến để phát hiện. Chọn một phân phối bằng nhau là - nói đơn giản - trung tính hơn.

Phím tắt

Nếu bạn có nhiều tệp và bạn muốn phát hiện các thay đổi đối với tệp, hãy sử dụng kích thước tệp và dấu thời gian sửa đổi lần cuối.

Có thể hệ điều hành bạn sử dụng cung cấp các phương tiện để phát hiện các thay đổi tệp, ví dụ Linux cho phép nhận thông báo về các thay đổi đối với các thư mục.

Xử lý tập tin đầy đủ

Nếu bạn cần đọc nội dung thực tế của các tệp để kiểm tra xem các tệp đã thay đổi hay chưa, hãy đi với hàm băm mật mã thực tế. CRC có tiềm năng đáng kể trong việc đưa ra một tiêu cực sai. SHA-256 có thể khá tốt, nhưng thực sự, SHA-512 nhanh hơn trên nhiều nền tảng hiện đại.

Nếu bạn có nhiều lõi CPU, có thể hữu ích khi tính toán các giá trị băm khác nhau cho các phần khác nhau của tệp hoặc sử dụng cây băm để xử lý song song.

Lý do đề xuất hàm băm thích hợp là một khi bạn truy cập dữ liệu tệp thực tế, quá trình xử lý mật mã sẽ không quá nhiều, thay vào đó sẽ có rất nhiều thứ chậm hơn khác, ví dụ như I / O đĩa hoặc gửi và nhận gói mạng.

Lưu ý: Đối với (ít nhất) các tệp nhỏ, cũng có thể lưu trữ toàn bộ nội dung tệp và so sánh nội dung thay vì băm.

Lưu ý 2: Nếu bạn rất chặt chẽ về lưu trữ, CRC hoặc băm mật mã bị cắt ngắn có thể là lựa chọn tốt. CRC32 mất 4 byte cho mỗi tệp và SHA-256 là 32 byte. Thẻ nhỏ 4 byte không thể bảo vệ chống lại các nỗ lực độc hại để ẩn các chỉnh sửa.

Xử lý tập tin một phần

Trong hầu hết các trường hợp, tôi khuyên bạn chỉ nên sử dụng xử lý tệp đầy đủ.

Có thể bây giờ đây là câu hỏi Toán học nhiều hơn, nhưng: khả năng phát hiện thay đổi bằng cách sử dụng kết hợp kích thước tệp, đầu, đuôi và dữ liệu ngẫu nhiên để tạo ra tổng băm nhanh này?

Đối với các tệp hình ảnh, thông thường thực hiện các chỉnh sửa nhỏ, như xóa mắt đỏ, thêm ria mép hoặc sừng, v.v. Những chỉnh sửa này ở định dạng JPG đôi khi sẽ không ảnh hưởng đến kích thước tệp (với chương trình chỉnh sửa có thể thay đổi đối với JPG chỉ được thay đổi các khu vực) hoặc một trong những thuộc tính khác mà bạn đề cập.

Thời gian sửa đổi tập tin thường sẽ bị ảnh hưởng.

Xem xét các tệp video: nhiều định dạng video tạo ra tốc độ bit không đổi. Đối với tệp tốc độ bit không đổi, nếu một số khung ở giữa bị thay đổi, nó cũng sẽ không xuất hiện ở kích thước tệp, đầu hoặc đuôi. Loại bỏ hoặc thêm khung hình sẽ luôn luôn dẫn đến sự khác biệt về kích thước.

Vì vậy, tôi thấy hoàn toàn có thể trường đó có các thay đổi mà không bị phát hiện.

Rất khó để ước tính các chỉnh sửa xác suất được phát hiện với sơ đồ này, nhưng có các tình huống sử dụng phổ biến cho video và hình ảnh không được phát hiện đúng.