2012-03-26 161 views
2

我想加密小序列化的數據結構(〜256字節),所以我可以安全地將它們傳遞(特別是在URL中)。我目前的方法是使用對稱分組密碼,然後進行基礎64編碼,然後對密文進行URL編碼。這產生了一個編碼密碼文本,(不出所料)比原始數據結構長得多。這些編碼密碼的長度有點可用性問題;理想情況下,我希望密文的長度與輸入文本的長度相同。密碼生成無安全編碼的URL安全密文

是否有可以配置爲將輸出字節的值限制在URL安全範圍內的分組密碼?如果有的話,我認爲會涉及安全權衡。

回答

2

對於給定的密鑰K,密碼必須爲每個明文產生不同的密文。如果您的消息空間是256字節,則密碼必須能夠產生至少256^256個不同的消息。這將需要至少256個字節,並且任何輸出字母表大小的減小都需要較長的消息。如你所見,你可以在後面做一些編碼,以避免某些輸出符號,代價是增加長度。此外,如果編碼是適當的加密算法的一部分,您將支付相同的費用。這就是爲什麼這不是任何加密算法的功能。

正如其他人所提到的,唯一真正的答案是減少您正在加密的數據的大小,以便您需要編碼更少的數據。 (或者不要將數據放在網址中,例如將數據存儲在數據庫中,並在URL中放入一個唯一的ID)。所以壓縮>加密>編碼。

+0

這正是我正在建議的。存儲你的數據服務器端並傳遞一個散列標記,如sha1散列標識該數據庫中的記錄。然後,您只需處理40個不需要base64編碼或urlencoded的字母數字字符,並且您可以輕鬆,安全且安全地將其從自己的服務器中拉出來引用數據,而不會將編碼數據暴露給每個站點訪問者要求黑客嘗試打破你的加密並破壞你的網站。 – Brian 2012-03-26 19:06:42

1

URL編碼不會顯着擴展base64編碼的字符串,因爲64個字符中的62個不需要修改。但是,您可以使用modified base64 encoding做更好一點。此編碼使用' - '和'_'字符代替'+'和'/'字符,以提高效率。

密碼本身不會導致任何重要的數據擴展。它會將數據填充爲塊長度的倍數,但在您的情況下,這是無關緊要的。您可以嘗試在加密之前壓縮輸入。 256字節並不多,但你可能會看到一些改進。

1

如果您的數據結構長度爲256個字節,用8個字節的分組密碼對其進行加密,最多可以將其增加到8個字節(取決於具體的輸入長度)。

因此,在應用base64之前,最多有264個字節,它們由base64編碼增加到352個字節。

因此,你可以看到最多的開銷是由base64編碼創建的。有一些稍微更有效的編碼可以像base91那樣 - 但它們非常罕見。

如果大小很重要,我建議在加密之前先壓縮數據。