哈希演算法配置

『壹』 怎樣加固網路防火牆

推薦在H3C防火牆上啟用SNMPv3協議，並配合高復雜度的用戶名和密碼。如下配置：
//開啟SNMP協議，使用戶可以讀寫節點snmp下的對象，並且創建MIB視圖firewall。
<H3C> system-view
[H3C] snmp-snmp
[H3C] snmp-agent mib-view included firewall snmp
[H3C] snmp-agent group v3 firewallmanager read-view firewall write-view firewall
//配置用戶名為firewalluser，認證哈希演算法為MD5，認證密碼為h3cfirewall，加密演算法為AES，加密密碼為h3cmanagement。
[H3C] snmp-agent usm-user v3 firewalluser firewallmanager authentication-mode md5 h3cfirewall privacy-mode aesh3cmanagement
//配置設備的聯系人和位置信息，以便維護。
[H3C] snmp-agent sys-info contact Mr.H3C-Tel:4008100504
[H3C] snmp-agent sys-info location Hangzhou, China
如果使用的是SNMPv2c協議，請盡量配置較復雜的讀寫團體字：
//配置SNMP版本為v2c，只讀團體字為h3cfirewall，寫團體字為h3cmanagement。
<H3C> system-view
[H3C] snmp-agent sys-info version v2c
[H3C] snmp-agent community read h3cfirewall
[H3C] snmp-agent community write h3cmanagement
最後，普及一個知識點，H3C防火牆的運維中，常常會配置哈希和加密演算法，推薦在網路中使用安全性較高的演算法，常用的演算法安全性比較如下：
哈希演算法: SHA1>MD5
加密演算法： AES>3DES>DES

『貳』 如何對網頁進行哈希演算法跪求大神回答！

網頁進行哈希演算法!?
大致有以下步驟： 對存儲對象的關鍵字進行哈希運算，得到鍵值。這樣就將所有的對象映射到了一個具體的數值范圍中。 重疊網中的每個節點負責數值范圍中的特定段落。例如，節點A負責存儲鍵值從8000到8999的對象；而節點B負責7000~7999的對象。這樣就將對象集合分布地存儲在所有的節點中。 節點可以直接存儲對象本身，如文件中的一個片段；也可以存儲對象的索引，如該對象所在節點的IP地址。 結構化的分布式存儲問題解決後，剩下的問題就是用戶如何才能找到存儲著目標信息的節點。在有著大量節點(如100萬個)的P2P系統中，任何節點都不可能擁有全部的節點?鍵值?內容的對應關系；因此用戶獲得了鍵值之後，如何找到該鍵值對應的節點就被稱為DHT的路由問題。DHT協議必須定義優化的查找(路由)演算法來完成這一搜尋的工作。不同的DHT協議之間區別很大程度上就在於定義了不同的路由演算法。 DHT的應用非常簡潔----API簡單到只有一項輸入和一項輸出： 應用層將數據對象(文件、數據塊或索引)通過哈希演算法獲得鍵值，將該鍵值提交給DHT後，返回結果就是鍵值所在節點的IP地址。
哈希使用的關鍵字有2個，一個是代理的標識符(每個代理均有唯一的標識)，另一個是URL本身。存儲內容時，每個代理負責緩沖哈希鍵值最大的URL。這樣，當緩沖代理陣列發生少量變化時(新的代理加入或舊的代理退出)，原有的URL還有可能仍然被映射到原來的代理上，仍可以按照原有的方式訪問。 路由演算法 客戶端(HTTP瀏覽器)首先載入一個代理配置文件，該文件中存儲了代理的標識符和IP地址等用於哈希的關鍵參數。瀏覽器在訪問網頁時，可以根據URL和代理標識獲得代理的位置信息(IP地址)，從而可以直接訪問緩沖代理中的頁面。

『叄』 哈希表map和table哪個性能高

list支持快速的插入和刪除，但是查找費時;
vector支持快速的查找，但是插入費時。
map查找的時間復雜度是對數的，這幾乎是最快的，hash也是對數的。
如果我自己寫，我也會用二叉檢索樹，它在大部分情況下可以保證對數復雜度，最壞情況是常數復雜度，而std::map在任何情況下都可以保證對數復雜度，原因是它保證存諸結構是完全二叉檢索樹，但這會在存諸上犧牲一些時間。
STL 中的 map 內部是平衡二叉樹，所以平衡二叉樹的性質都具備。查找數據的時間也是對數時間。 vector，在分配內存上一般要比 new 高效的多。
為什麼說 hash_map 是對數級的？在不碰撞的情況下，hash_map是所有數據結構中查找最快的，它是常數級的。
如果對問題設計了足夠好的hash演算法，保證碰撞率很低，hash_map的查找效率無可置疑。
另外，STL的map，它的查找是對數級的，是除hash_map外最高的了，你可以說「也許還有改進餘地」，但對於99.9999%的程序員，設計一個比STL map好的map，我執悲觀態度。
STL的map有平衡策略（比如紅黑樹什麼的），所以不會退化，不需要考慮數據本身的分布問題。只不過，如果數據本身是排好序的，用vector或heap會明顯的快些，因為它們的訪問比較簡單。

我想沒必要懷疑stl::map的查找效率,影響效率最主要的因素是什麼?演算法,在查找問題上,有什麼演算法比RB_tree更好嗎？至少現在還沒有。不否 認你可以通過自己寫代碼，設計一個符合你需要的BR—TREE，比stl：：map簡捷那麼一點，但最多也就每次迭代中少一行指令而已，處理十萬個數據多 執行十萬行指令，這對你重要嗎？如果你不是在設計OS像Linux，沒人會關注這十萬行指令花的時間。
rb-tree的時間花在了插入和刪除上，如果你不是對插入和刪除效率要求很高，你沒有理由不選擇基於rb-tree的stl::map。

大多數程序員寫不出比std::map更好的map，這是當然的。然而並不是std::map的所有特性都出現在我們的程序中，自己編寫的可以更適合自己的程序，的確會比std::map更快一些。

關於hash_map，它與map的實現機制是不一樣的，map內部一般用樹來實現，其查找操作是O(logN)的，這個沒有爭議，我就不多說了。
hash_map的查找，內部是通過一個從key到value的運算函數來實現的，這個函數「只接受key作為參數」，也就是說，hash_map的查找 演算法與數據量無關，所以認為它是O(1)級的。來這里的應該都是達人，可以參看《數據結構》。當然，事實總不這樣完美，再引一段前面我自已說的話，進一步 說明，以免誤會：
-----------------------------------------
在不碰撞的情況下，hash_map是所有數據結構中查找最快的，它是常數級的。
------------------------------------------
注意我的前提：「在不碰撞的情況下」，其實換句話說，就是要有足夠好的hash函數，它要能使key到value的映射足夠均勻，否則，在最壞的情況下，它的計算量就退化到O(N)級，變成和鏈表一樣。
如果說 hash_map 是所有容器中最慢的，也只能說：「最拙劣的hash函數」會使hash_map成為查找最慢的容器。但這樣說意義不大，因為，最湊巧的排列能使冒泡排序成為最快的排序演算法。
BS: "對於大型容器而言,hash_map能夠提供比map快5至10倍的元素查找速度是很常見的,尤其是在查找速度特別重要的地方.另一方面,如果hash_map選擇了病態的散列函數,他也可能比map慢得多. "
ANSIC++在1998年之後就沒再有重大改變，並且決定不再向C++標准庫中做任何重大的變更，正是這個原因，hash table(包括hash_map)並沒有被列入標准之中，雖然它理應在C++標准之中佔有一席之地。
雖然，現在的大多數編譯平台支持hash table，但從可移植性方面考慮，還是不用hash table的好。

hehe俺也來湊湊熱鬧。
1.有的時候vector可以替代map
比如key是整數，就可以以key的跨度作為長度來定義vector。
數據規模很大的時候，差異是驚人的。當然，空間浪費往往也驚人。
2.hash是很難的東西
沒有高效低碰撞的演算法，hash_xxx沒有意義。
而對不同的類型，數據集，不可能有優良的神仙演算法。必須因場合而宜。
俺有的解決方法是GP，可不是飯型，是遺傳編程，收效不錯。

你的百萬級的數據放到vector不大合適。因為vector需要連續的內存空間，顯然在初始化這個容器的時候會花費很大的容量。
使用map，你想好了要為其建立一個主鍵嗎？如果沒有這樣的需求，為什麼不考慮deque或者list？
map默認使用的是deque作為容器。其實map不是容器，拿它與容器比較意義不大。因為你可以配置它的底層容器類型。

如果內存不是考慮的問題。用vector比map好。map每插入一個數據，都要排序一次。所以速度反不及先安插所有元素，再進行排序。
用 binary_search對已序區間搜索，如果是隨機存取iterator，則是對數復雜度。可見，在不考慮內存問題的情況下，vector比map 好。

如果你需要在數據中間進行插入，list 是最好的選擇，vector 的插入效率會讓你痛苦得想死。

涉及到查找的話用map比較好，因為map的內部數據結構用rb-tree實現，而用vector你只能用線性查找，效率很低。
stl還提供了 hash容器，理論上查找是飛快~~~。做有序插入的話vector是噩夢，map則保證肯定是按key排序的，list要自己做些事情。

HASH類型的查找肯定快，是映射關系嘛，但是插入和刪除卻慢，要做移動操作, LIST類型的使鏈式關系，插入非常快，但是查找卻費時，需要遍歷~~ , 還是用LIST類型的吧，雖然查找慢點，
先快速排序，然後二分查找，效率也不低

『肆』 memcache 怎麼設置一致性哈希

memcache 是一個分布式的緩存系統，但是本身沒有提供集群功能，在大型應用的情況下容易成為瓶頸。但是客戶端這個時候可以自由擴展，分兩階段實現。第一階段：key 要先根據一定的演算法映射到一台memcache伺服器。第二階段從伺服器中取出緩存的值。但是有一個問題，比如其中一台伺服器掛了，或者需要增加一台服務 的時候，這個時候第一階段的演算法就很重要了，怎樣使得原來的數據盡可能的繼續有效，減少擴展節點或縮減節點帶來的沖擊。考慮通常的 hash 演算法都是將 value 映射到一個 32 為的 key 值，也即是 0~2^32-1 次方的數值空間；我們可以將這個空間想像成一個首（ 0）尾（ 2^32-1 ）相接的圓環

『伍』 03組策略哈希規則是什麼

哈希是唯一標識軟體程序或可執行文件（即使該程序或可執行文件已被移動或重命名）的指印。這樣，管理員可以使用哈希來跟蹤他（或她）不希望用戶運行的特定版本的可執行文件或程序。如果程序在安全或隱私方面存在漏洞，或者可能會破壞系統的穩定性，則可以使用哈希規則。

使用哈希規則，軟體程序始終具有唯一可標識性，因為哈希規則匹配基於涉及文件內容的加密計算。唯一受哈希規則影響的文件類型是在「軟體限制策略」的詳細信息窗格中「指派的文件類型」部分列出的那些文件類型。

哈希規則比較適合於靜態環境。如果客戶端中的軟體經常升級，則應在每個程序更新後將哈希重新應用於其可執行文件。哈希規則非常適用於未向其相應程序的可執行文件應用更改或升級的環境。

哈希規則由下列三個數據段組成，並以冒號分隔：

MD5 或 SHA-1 哈希值。

文件長度。

哈希演算法 ID 編號。

數字簽名文件使用簽名中包含的哈希值（可能是 MD5 或 SHA-1）。非數字簽名的可執行文件使用 MD5 哈希值。

哈希規則的格式如下所示：

[MD5 或 SHA1 哈希值]：[文件長度]：[哈希演算法 ID]

以下哈希規則示例用於內容與 MD5 哈希值（由哈希演算法標識符 32771 表示）和哈希演算法 相匹配的 126 個位元組長的文件：

：126：32771

管理員要限制或允許的每個文件都需要包含一個哈希規則。軟體更新後，由於原始可執行文件的哈希值通常已被覆蓋，因此管理員必須為每個應用程序新建一個哈希規則。。

『陸』 華為9700s-s配置實例

摘要 加密演算法約定

『柒』 spring提供的幾種密碼加密方式

第一種：不使用任何加密方式的配置

[html]view plain

• <beanid="AuthenticationProvider"

• class="org.acegisecurity.providers..DaoAuthenticationProvider">

• <propertyname="userDetailsService"ref="userDetailsService"/>

• <!--明文加密，不使用任何加密演算法,在不指定該配置的情況下，Acegi默認採用的就是明文加密-->

• <!--<propertyname="passwordEncoder"><beanclass="org.acegisecurity.providers.encoding.PlaintextPasswordEncoder">

• <propertyname="ignorePasswordCase"value="true"></property></bean></property>-->

• </bean>


第二種：MD5方式加密



[html]view plain

• <beanid="AuthenticationProvider"class="org.acegisecurity.providers..DaoAuthenticationProvider">

• <propertyname="userDetailsService"ref="userDetailsService"/>

• <propertyname="passwordEncoder">

• <beanclass="org.acegisecurity.providers.encoding.Md5PasswordEncoder">

• <!--false表示：生成32位的Hex版,這也是encodeHashAsBase64的,Acegi默認配置;true表示：生成24位的Base64版-->

• <propertyname="encodeHashAsBase64"value="false"/>

• </bean>

• </property>

• </bean>


第三種：使用MD5加密，並添加全局加密鹽



java代碼

[html]view plain

• <beanid="AuthenticationProvider"class="org.acegisecurity.providers..DaoAuthenticationProvider">

• <propertyname="userDetailsService"ref="userDetailsService"/>

• <propertyname="passwordEncoder">

• <beanclass="org.acegisecurity.providers.encoding.Md5PasswordEncoder">

• <propertyname="encodeHashAsBase64"value="false"/>

• </bean>

• </property>

• <!--對密碼加密演算法中使用特定的加密鹽及種子-->

• <propertyname="saltSource">

• <beanclass="org.acegisecurity.providers..salt.SystemWideSaltSource">

• <propertyname="systemWideSalt"value="acegisalt"/>

• </bean>

• </property>

• </bean>


第四種：使用MD5加密，並添加動態加密鹽

[html]view plain

• <beanid="AuthenticationProvider"class="org.acegisecurity.providers..DaoAuthenticationProvider">

• <propertyname="userDetailsService"ref="userDetailsService"/>

• <propertyname="passwordEncoder">

• <beanclass="org.acegisecurity.providers.encoding.Md5PasswordEncoder">

• <propertyname="encodeHashAsBase64"value="false"/>

• </bean>

• </property>

• <!--對密碼加密演算法中使用特定的加密鹽及種子-->

• <propertyname="saltSource">

• <!--通過動態的加密鹽進行加密，該配置通過用戶名提供加密鹽,通過UserDetails的getUsername()方式-->

• <beanclass="org.acegisecurity.providers..salt.ReflectionSaltSource">

• <propertyname="userPropertyToUse"value="getUsername"/>

• </bean>

• </property>

• </bean>

第五種：使用哈希演算法加密，加密強度為256

[html]view plain

• <beanid="AuthenticationProvider"class="org.acegisecurity.providers..DaoAuthenticationProvider">

• <propertyname="userDetailsService"ref="userDetailsService"/>

• <propertyname="passwordEncoder">

• <beanclass="org.acegisecurity.providers.encoding.ShaPasswordEncoder">

• <constructor-argvalue="256"/>

• <propertyname="encodeHashAsBase64"value="false"/>

• </bean>

• </property>

• </bean>

第六種：使用哈希演算法加密，加密強度為SHA-256


[html]view plain

• <beanid="AuthenticationProvider"class="org.acegisecurity.providers..DaoAuthenticationProvider">

• <propertyname="userDetailsService"ref="userDetailsService"/>

• <propertyname="passwordEncoder">

• <beanclass="org.acegisecurity.providers.encoding.ShaPasswordEncoder">

• <constructor-argvalue="SHA-256"/>

• <propertyname="encodeHashAsBase64"value="false"/>

• </bean>

• </property>

• </bean>


上述配置只是在Acegi通過表單提交的用戶認證信息中的密碼做各種加密操作。而我們存儲用戶密碼的時候，可以通過一下程序完成用戶密碼操作：



[java]view plain

• packageorg.hz.test;

• importjava.security.NoSuchAlgorithmException;

• importorg.springframework.security.authentication.encoding.Md5PasswordEncoder;

• importorg.springframework.security.authentication.encoding.ShaPasswordEncoder;

• publicclassMD5Test{

• publicstaticvoidmd5(){

• Md5PasswordEncodermd5=newMd5PasswordEncoder();

• //false表示：生成32位的Hex版,這也是encodeHashAsBase64的,Acegi默認配置;true表示：生成24位的Base64版

• md5.setEncodeHashAsBase64(false);

• Stringpwd=md5.encodePassword("1234",null);

• System.out.println("MD5:"+pwd+"len="+pwd.length());

• }

• publicstaticvoidsha_256(){

• ShaPasswordEncodersha=newShaPasswordEncoder(256);

• sha.setEncodeHashAsBase64(true);

• Stringpwd=sha.encodePassword("1234",null);

• System.out.println("哈希演算法256:"+pwd+"len="+pwd.length());

• }

• publicstaticvoidsha_SHA_256(){

• ShaPasswordEncodersha=newShaPasswordEncoder();

• sha.setEncodeHashAsBase64(false);

• Stringpwd=sha.encodePassword("1234",null);

• System.out.println("哈希演算法SHA-256:"+pwd+"len="+pwd.length());

• }

• publicstaticvoidmd5_SystemWideSaltSource(){

• Md5PasswordEncodermd5=newMd5PasswordEncoder();

• md5.setEncodeHashAsBase64(false);

• //使用動態加密鹽的只需要在注冊用戶的時候將第二個參數換成用戶名即可

• Stringpwd=md5.encodePassword("1234","acegisalt");

• System.out.println("MD5SystemWideSaltSource:"+pwd+"len="+pwd.length());

• }

• publicstaticvoidmain(String[]args){

• md5();//使用簡單的MD5加密方式

• sha_256();//使用256的哈希演算法(SHA)加密

• sha_SHA_256();//使用SHA-256的哈希演算法(SHA)加密

• md5_SystemWideSaltSource();//使用MD5再加全局加密鹽加密的方式加密

• }

• }

『捌』 一個安全的散列演算法需要具備哪些屬性

一個安全的散列演算法需要具備的屬性：
1、能對抗野蠻的攻擊，能夠抵禦窮舉法的攻勢。
2、具有無限定義域，如任意長度的位元組字元串和有限的值域或者固定長度的比特串。
3、具備應用的多樣性，對於給定的散列值，沒有實用的方法可以計算出一個原始輸入，也就是說很難偽造。
4、能夠因為環境因素的變化，如機器配置或者IP地址的改變而有變動。以保證源文件的安全性。
5、方便錯誤監測和修復函數。當散列函數被用於校驗和的時候可以用相對較短的散列值來驗證任意長度的數據是否被更改過。
6、安全散列演算法接受的輸入文檔小於2的64次方 位，產生160位的報文摘要。該演算法實際的目標使得找出一個能夠匹配給定的散列值的文本是不可能的計算。

『玖』 請問java中HashMap是怎麼實現的，還有treeMap的實現原理是紅黑樹，請解釋一下紅黑樹

參考資料的網頁上有比較的代碼,你可以仔細看下~~~

java中HashMap,LinkedHashMap,TreeMap，HashTable的區別
java為數據結構中的映射定義了一個介面java.util.Map;它有四個實現類,分別是HashMap Hashtable LinkedHashMap 和TreeMap
Map主要用於存儲健值對，根據鍵得到值，因此不允許鍵重復(重復了覆蓋了),但允許值重復。
Hashmap 是一個最常用的Map,它根據鍵的HashCode 值存儲數據,根據鍵可以直接獲取它的值，具有很快的訪問速度，遍歷時，取得數據的順序是完全隨機的。HashMap最多隻允許一條記錄的鍵為Null;允許多條記錄的值為 Null;HashMap不支持線程的同步，即任一時刻可以有多個線程同時寫HashMap;可能會導致數據的不一致。如果需要同步，可以用 Collections的synchronizedMap方法使HashMap具有同步的能力，或者使用ConcurrentHashMap。
Hashtable與 HashMap類似,它繼承自Dictionary類，不同的是:它不允許記錄的鍵或者值為空;它支持線程的同步，即任一時刻只有一個線程能寫Hashtable,因此也導致了 Hashtable在寫入時會比較慢。
LinkedHashMap保存了記錄的插入順序，在用Iterator遍歷LinkedHashMap時，先得到的記錄肯定是先插入的.也可以在構造時用帶參數，按照應用次數排序。在遍歷的時候會比HashMap慢，不過有種情況例外，當HashMap容量很大，實際數據較少時，遍歷起來可能會比LinkedHashMap慢，因為LinkedHashMap的遍歷速度只和實際數據有關，和容量無關，而HashMap的遍歷速度和他的容量有關。
TreeMap實現SortMap介面，能夠把它保存的記錄根據鍵排序,默認是按鍵值的升序排序，也可以指定排序的比較器，當用Iterator 遍歷TreeMap時，得到的記錄是排過序的。

一般情況下，我們用的最多的是HashMap,HashMap裡面存入的鍵值對在取出的時候是隨機的,它根據鍵的HashCode值存儲數據,根據鍵可以直接獲取它的值，具有很快的訪問速度。在Map 中插入、刪除和定位元素，HashMap 是最好的選擇。
TreeMap取出來的是排序後的鍵值對。但如果您要按自然順序或自定義順序遍歷鍵，那麼TreeMap會更好。
LinkedHashMap 是HashMap的一個子類，如果需要輸出的順序和輸入的相同,那麼用LinkedHashMap可以實現,它還可以按讀取順序來排列，像連接池中可以應用。