传统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)]。这个时间戳将很容易被怀疑者检验，并且不需要向下一个客户机发送检查请求。