在url動態加解密中,我使用的是des加解密,秘鑰使用當前系統時間轉換為的小時數:
1234567
8910
public static string encrypt(string data) throws exceptionreturn encrypt(data, key);
}
加密**如下所示:
1234567
891011
1213
1415
1617
1819
public final static string encrypt(string data, string key) throws exceptionprivate static byte encrypt(byte data, byte key) throws exception
在偶然中,我發現使用兩個不同的秘鑰00401888
和00401889
,對同樣的資料,加密出來的結果是一樣的。再一看,發現不僅僅這兩個秘鑰生成的結果是一樣的,比如00401880
和00401881
生成的加密結果也是一樣的。
仔細地除錯了一下**,又檢視了一下關於des加密演算法的說明,發現:
初始key值為64位,但des演算法規定,其中第8、16、……64位是奇偶校驗位,不參與des運算。故key 實際可用位數便只有56位於是明白原因了。
00401888
轉為byte陣列為, 比如其中
56
的二進位制表示為00111000
,但是參與des運算的只是前七位,即0011100
;
00401889
轉為byte陣列為, 其中
57
的二進位制表示為00111001
,但是參與des運算的只是前七位,即0011100
,跟上面的56
(即數字8的asc碼)是一樣的。所以造成了key不一樣,但是加密結果一樣的現象,本質原因是參與des運算的那些位是一樣的。
明白了這一點,就比較有趣了。比如我可以構造兩個完全不同的秘鑰0075309j
和1164218k
,它們對應的每乙個字元都不一樣,但是因為每乙個字元的二進位制表示,只有最後一位是不一樣的,前七位一樣,所以它們對同一段資料加密後的結果是完全一樣的。理論上是這樣,經過試驗結果確實如此。
git 檢視自己秘鑰 Git秘鑰問題
簡介 在管理git專案上,很多時候都是直接使用https url轉殖到本地,當然也有有些人使用ssh url轉殖到本地。這兩種方式的主要區別在於 使用https url轉殖對初學者來說會比較方便,複製https url然後到git bash裡面直接用clone命令轉殖到本地就好了,但是每次fetch...
Git秘鑰問題
在管理git專案上,很多時候都是直接使用https url轉殖到本地,當然也有有些人使用ssh url轉殖到本地。這兩種方式的主要區別在於 使用https url轉殖對初學者來說會比較方便,複製https url然後到git bash裡面直接用clone命令轉殖到本地就好了,但是每次fetch和pu...
SSH公鑰秘鑰
可是碼雲不認識你是誰,這個時候就提示你輸入賬號密碼來確認是誰誰誰提交了這次 往後的日子裡每次修改提交 都需要輸入賬號密碼來確認身份,這是個很煩的事情,所以出現了 ssh 公鑰 這種形式來解決這個問題。使用 git,第一件事就是通過使用者名稱密碼生成公鑰和私鑰,這是一一對應的關係,就像一把鑰匙開一把鎖...