加密和壓縮文件名

Question

說，我有一個對象的信息的文件。我有一個名字創建它，這樣文件名本身包含像對象ID的對象，對象父節點編號，其他一些元ID信息和文件序列號的某些信息。這是因爲文件可用acorss不同的模塊，並避免多個數據庫訪問文件的元信息。

文件名= 「OB」 + FILEID + parentId的+ metaId +序列+ 「TXT」

序列開始從00001到99999（可能是非常大的也）

因此，每一索引在每個數位具有一個具體的含義

現在，文件信息將被提供給我們的應用程序之外的程序，我不希望其他應用程序知道我使用的細節。因此，我想使用加密或哈希在發送文件之前，在文件中的響應文件名也被加密或散列，並且他們應該給我一個響應NSE與基於文件的內容加密/散列響應文件名

有2個challanges：

1. 要做到這一點，而不涉及數據庫

2. 文件名是最快和最簡單的方法長大約25個字符（和其它ID和序列信息），所以想要得到的文件名得較小（儘可能小）和標準尺寸的。

或者可以使用的任何其他機制???

Answer 1

選項1哈希

使用密碼散列算法如SHA-256和SHA-128將讓你的文件名較長，雖然將提供不錯保證它的唯一沒有什麼低保（所有哈希算法都受到生日悖論的影響）。

由於沒有低保SHA-256和SHA-128將生成是唯一的一個文件名的，並且根據安全級別，你需要你可能想看看的Adler32。該算法不會是任何接近的SHA家人的安全，主要是因爲所產生的散列大小是如此之小，你可以蠻力它很容易。但是，Adler32可以提供對文件名稱的模糊處理。

由於Alder32產生的哈希大小很小（32位），所以碰撞的機會也比SHA家族高得多，因此您肯定需要保留某種具有您的文件名和相應的表的對應表散列值（並在此或SHA案例中推薦）。該表可以存儲在緩存中的簡單列表，但最主要的原因是，如果你得到一個碰撞，你需要改變你的值來計算一個新的哈希。

選項2加密

加密不會讓你的數據更小，充其量這將是相同的尺寸（如果你的數據的大小整除算法的塊大小）。但是，它將保留所有數據，而不需要保留表格的加密值。如果你決定採用加密技術而不是散列技術，那麼除了目前的標準外，我不會使用AES。加密文件名是少量的數據，你可能不會注意到算法之間的差異，但如果你足夠偏執，你可以查看Intel CPU's上的AES指令集。