書接上文，我們知道了ec=1時的current key生成流程和交易處理流程，那麼後續ec=2、ec=3…ec=n的情況呢？
我們回頭看一下上文中提到的」發生交易時，pos的處理「：
1>current ksn = iksn and ec++
2>current pek = pek_derive(initial pek, current ksn)
3>encrypted pin = t-des(opr=encrypt, current pek, clear pin)
4>把current ksn和encrypted pin放到交易報文裡面，傳送給acquirer host
其實這裡我有些偷懶了（表打我哦…），想一下，在這個追求使用者體驗的年代，刷卡交易的速度一定是評估刷卡體驗的重要指標。
那麼，為了提高速度，怎麼簡化一下上述流程呢？拋開演算法層面的優化，很自然的乙個想法：把能提起做的事情，先提前做起來！
哪些步驟可以提前做？看看上述流程中每個步驟的入參，好像只有clear pin是持卡人在交易發生時輸入的，其它引數不都是pos內部的資料麼！
這是個好訊息！這樣的話，我們可以在初始化pos（想想上文提到的「初始化」流程）時，就把ec=2、ec=3…ec=n時的每個ec對應的(current key)i計算出來，提前儲存到pos中，交易發生時，只需要ec++並取出相應的(current key)i，就萬事大吉啦！
呃，好像有**不對的樣子……哦哦哦，ec=2、ec=3…ec=n，這個n到底是多少啊？要是有個幾十上百萬，pos中哪有那麼大的空間給你存(current key)i呢！要知道，pos的硬體就那麼一塊小板子，每乙個位元組都是很寶貴的哦！
該死的，又是時間和空間互換的問題，那就找個平衡點咯！於是乎，ansi果斷的找到了這個平衡點：pos中預先儲存的current key（插一句，這些key都是後續交易中，ec++之後才用到的key，是不是應該叫做future key啊？）數量，是21個！
【為啥是21？我咋知道！或許是這個數字比較吉利？不過想想ec的長度也是21個bit，好像發現了點兒神馬哦…】
於是，pos中出現了21個暫存器，叫做future key register，在pos初始化時，它們被依次填充了ec=1 … ec=21的future key
於是，我們更新一下pos初始化的流程：
1> acquirer給pos灌輸bdk
2>initial pek = pek_derive(bdk, ksn with ec=0)
3>
(future key)1 = pek_derive(initial pek, ksn with ec=1)->(future key register)1
(future key)2 = pek_derive(initial pek, ksn with ec=2)->(future key register)2
……
(future key)21 = pek_derive(initial pek, ksn with ec=21)->(future key register)21
4> 為了保證金鑰安全性，別忘了銷毀bdk和initial pek！
ok啦，pos曰：萬事大吉，坐等刷卡！
那麼，21個future key用完了咋辦？當然後面接著生成啦。這裡就有2個新問題了：
比較明顯的問題：什麼時機去生成和更新ec=22、ec=23…的future key？
既然pos中只有21個暫存器，那當然得物盡其用啦！反正ec又不會重複使用（ec++操作是有上限的哦，後面會提到），ec=1的future key用過一次之後，就木有用啦！
那就在pos的第一筆交易處理完成後，把(future key register)1中儲存的key，更新成(future key)22吧！這樣既不影響交易處理效率，又可以充分利用空間，多好啊！
比較隱晦的問題：(future key)22是怎麼生成的呢？
最直接的想法，跟(future key)1採用同樣的方式唄：
(future key)22 = pek_derive(initial pek, ksn with ec=22)->(future key register)1
stop！pos曰：我去哪兒找initial pek啊？之前初始化的第4步裡面，已經把這玩意兒銷毀了哎！
呃，有點兒麻煩了，是之前不應該銷毀initial pek嗎？可是如果不銷毀，後續所有的key，都由initial pek分散得到的話，那這個initial pek可是個相當重要、相當機密的東東啦！
嘿，換個思路如何？我現在是要生成(future key)22，而它要占用的地盤兒（暫存器），正是(future key register)1，那我乾脆就用(future key)1來分散得到(future key)22吧！
於是：(future key)22 = pek_derive( (future key)1 , ksn with ec=22)->(future key register)1
ok，總算是把(future key)22搞定了，接下來就好說啦，以此類推唄：
(future key)23 = pek_derive( (future key)2 , ksn with ec=23)->(future key register)2
(future key)24 = pek_derive( (future key)3 , ksn with ec=24)->(future key register)3
……
(future key)42 = pek_derive( (future key)21
, ksn with ec=42)->(future key register)21
哦，又是21，好巧哦，又是乙個輪迴啊！接下來咋辦？
(future key)43 = pek_derive( (future key)?
, ksn with ec=43)->(future key register)?
好辦啊！跟(future key)22一樣處理唄：
(future key)43 = pek_derive( (future key)22
, ksn with ec=43)->(future key register)1
……
呃，今天先到這兒吧，老婆喊我回家吃飯呢……
DUKPT演算法簡析 3
不好意思隔了這麼久才發 其實前文已經將dukpt演算法解釋的差不多了，需要進一步說明的，就是future key的計算了。其實之前已經推理了一大堆了，我就直接把結果貼出來吧 ec共有21個bit，每個bit可能的取值為 0 或 1 那麼如此多的ec，可以形成一棵樹狀結構 說明一下，這棵樹的組成是這樣...
DUKPT演算法解析
dukpt derived unique key per transaction 1 是什麼？是一種非常安全的金鑰管理技術，主要應用於對稱金鑰加密mac,pin等安全資料方面 2 主要思想 保證每一次交易流程使用唯一的金鑰，採用一種不可逆的金鑰轉換演算法，使得無法從當前交易資料資訊破解上一次交易金鑰...
執行緒簡析2
正確停止執行緒 not stop 方法 stop方法會造成戛然而止突然停止的情況。thread的interrupt方法用於停止執行緒是錯誤的。interrupt方法用於中斷執行緒，能使中斷標誌發生改變。正確的停止執行緒方法的操作應該是設定退出標誌，有利於清理資源。爭用條件 當多個執行緒同時共享訪問同...