傳統TSS時間戳實現以及分佈式時間戳的實現。
思考：這兩種時間戳不可僞造嗎？
更改時間戳字符串不可以嗎？
先例舉一種比較幼稚的方法：數字保險箱
每當客戶機有一個要加蓋時間戳的文件時，就將文檔發送到時間戳服務器（TSS）。服務記錄收到文件的日期和時間，並保存文件的副本以備保管。如果需要驗證客戶機的文檔的完整性或是否被篡改時，它可以與TSS存儲的副本進行比較，如果它們是相同的，則表明，在TSS記錄的日期之後，該文檔沒有被篡改。這起到了驗證的要求，但它的缺點也很明顯。
1，隱私保護方面
在傳輸文件時，這份文件有被第三方竊取的風險。另外儲存在TSS上的文件安全性也令人擔憂。
2，帶寬與存儲
TSS所需的存儲量取決於文檔的長度，所以當文件過於龐大時，蘇哦需要花費的時間以及存儲空間是巨大的。
一種被信任的時間戳服務
4.1hash
這種函數家族（hash）可以將任意長度的字符串壓縮到一個固定長度，並且具有以下特性。
（1）、該函數H很容易計算，並且很容易從定義域中隨機取值。
（2）、並且找到使H(x)=H(x’)成立的（x，x’）在計算上是不可行的（不能由函數值推知x）
對要發送的文本進行hash加密，對加密後的H(x)打時間戳。
4.2，簽名技術
用戶將hash過的字符串發送給TSS，TSS根據日期及時間將文件簽名，再將文件發送給用戶，這就免去了在TSS上存儲文件的需要。
通過檢查簽名，用戶確信TSS實際上處理了請求，散列得到了正確的接收，並且包含了正確的時間。
5，兩種新的打時間戳的方法
以上的兩中技術的使用都無法保證TSS故障的情況下，時間戳的正確性，所以，我們需要新方法。
一種方法是限制可能產生錯誤時間戳的TSS，另一種是在用戶間分配權重，共同決定時間戳。
5.1鏈式結構
有兩種該結構的變種，第一種比較好的描述了這種思想，第二種在工程上更加容易實現。
簡單的說在收到客戶的請求後TSS做了如下兩件事：
（1）、TSS將簽名證書即字符串s = G(Cn)發送給用戶。
Cn = (n,tn, idn, yn; Ln)
n爲序列號、tn爲時間、idn爲客戶編號，yn爲哈希值，Ln爲鏈接信息。Ln來自於上一個簽名的連接信息。
即Ln = (tn1,idn1.yn1.H(Ln-1))。
（2）、當下一個簽名需求發的送TSS後，TSS將idn+1發送給用戶。
所以，剛一個 用戶發送簽名請求時，他會收到兩樣東西，一個簽名s，該簽名的客戶編號id。
鏈式結構的驗證：
當有人懷疑簽名的正確性時，它可以查看這個簽名（s，idn），對s用解密，如果包含要驗證的文本x的hash值，則該簽名是可信的，表明該文檔確實在t時刻被簽名。當然，如果他懷疑用戶勾結TSS服務商僞造簽名的話，可以向idn+1用戶申請查看他的簽名（s’，idn+1）。s’中包含s的連接信息Ln的hash值。
TSS是對文件蓋上更早的時間戳的，因爲下一個時間戳中包含該時間戳的連接信息的hash值，爲了蓋上這樣的時間戳，就必須僞造足夠長的時間戳鏈，而後面的時間戳已經分發出去了，所以這是不可能僞造的。
第二種變種如下：
上面的方法需要一個一個查詢下一個的簽名，所以做一下改進
(1)、現在，我們在Ln中存儲後k個的連接信息
Ln = [(tn-k,idn-k,yn-k,H(Ln-k))…(tn-1,idn-1,yn-1,H(Ln-1))]
（2）、當後k個簽名請求被髮送時，TSS再將 簽名發送給(idn+1… idn+k)用戶
這樣在驗證鏈時就可以驗證相當多的“下一個用戶”。
這種時間戳建立在TSS是被大家信任的前提下，我們確信通過TSS加密後的s是可信的，將解密後的內容（時間）同樣真實可信。
5.2分佈式信任
在這種方法中，我們不需要中央服務器TSS，每個節點都將對該文件蓋時間戳。
有這樣一個函數M（y）=（id1,id2,id3…idk）
假設客戶機有一段字符y需要加蓋時間戳，則他使用M函數將y映射成k個客戶機的編號。
客戶機發送（y，id）給所映射的k個節點，他將收到每個節點反饋回的時間戳sj=G（t,id,y）。那麼該客戶機的時間戳將會是[(y,id),(s1,s2,s3…sj)]。這個時間戳將很容易被懷疑者檢驗，並且不需要向下一個客戶機發送檢查請求。