Frequently Asked Questions
If you have any questions regarding our service, please use the form below to send it to us.
GuardTime Service
- What is the capacity of the GuardTime system in terms of volume of timestamp requests that can be supported?
- The theoretical capacity of the GuardTime system is determined only by the strength of the hash function; thus the system can theoretically support over 2^100 timestamps per second. However, due to clustering at each node in order to provide higher redundancy, the system can be safely said to be able to support over 4 billion timestamps per second assuming full roll-out of the aggregation grid and gateway nodes. The capacity of the GuardTime global service at any given moment is determined by the number of Gateway nodes and the supporting aggregation grid.
- If I have my own Gateway, how many timestamp requests can I make per second?
- The throughput of a single Gateway server is limited by its performance or concurrency limitations within the software. In current software the concurrency limitation is set at 900, which limits the throughput at around 900 timestamps per second. That throughput has been tested and achieved on a Dual-Xeon class server system. For higher throughput, multiple Gateways can be installed and all means of webserver load-balancing methods can be used. For extremely high performance requirements the gateway functionality can be “deeply integrated” into an application removing the need for concurrency giving potential volume measured in millions of requests per second.
- What if I exceed the number of requests/second that the Gateway supports?
- The Gateway uses a webserver to arbitrate access to the aggregation grid. When performance or concurrency limits are reached, the effect would be an increase in service waiting time.
- How do I optimize the request/response communications cost?
- The Gateway timestamp response is around 4Kbytes. Each application request of around 200 bytes receives a gateway response of around 4Kbytes. Note that although the response per request is 4KB that does not imply that 4KB of storage is required per request. For high volume applications the overlap between timestamps can reduce the storage requirements to less that 100Bytes per request
The Gateway connection to a grid cluster entails constant traffic of around 10Kbytes per second for each session (up to 4 sessions to the members of the cluster, for a total of 40KBytes/sec). Communication costs can be reduced by reducing the number of concurrent sessions to the grid, though this will entail a compromise on the redundancy.
- At the throughput of around 2-10 timestamps per second the traffic from the Gateway to the application and the traffic from the grid to the Gateway is about equal. If the average needed throughput is lower, then it is more cost-effective to use a remote Gateway; if the need is higher, then the Gateway should be placed closer to the application.
If the cost of the timestamp response communication is prohibitive, then the timestamp could be stored remotely and only notices about such an event could be sent.
- What is the GuardTime trust model, i.e. how do I trust the timestamp provided by GuardTime and which parts of the system need to blindly trusted?
- No parts of the GuardTime system need to be blindly trusted.
The GuardTime trust model relies on the following:
• Openness. There are no secrets based trust models;
• Easily auditable calendar hash database;
• Use of well-known algorithms (SHA2-256) and their widely-used implementations (OpenSSL);
• The client side application does all the verification, and reference implementations are provided as source code;
• Independent verification is possible and encouraged;
• GuardTime provides a means to authenticate the data received from the grid;
• GuardTime provides a means to audit its operations in real-time. - What is the core of GT’s technology in terms of cryptography and the network architecture?
- Based on our research in cryptography we have constructed a timestamping system that is mathematically secure against backdating. There are very few cryptographic applications that have such solid theoretical foundations. We do not know of any timestamping system with such characteristics.
Our timestamping system, like other timestamping systems, uses cryptographic primitives like hash functions and digital signatures. It is important to note that all such crypto primitives used in GuardTime timestamping system are currently de facto world standard, such as SHA2-256 and RSA. GuardTime timestamping service is engineered to provide high volumes of uniformly verifiable timestamps on a global scale. The service is implemented as a distributed network technology that could operate over electronic networks like the Internet, mobile networks, or phone networks. The network architecture is highly fault-tolerant, allowing to offer 24/7 timestamping service availability.
- What is the GuardTime Calendar?
- GuardTime Calendar is an accounting system that at every one second interval aggregates the hash values representing the timestamp requests received through the GuardTime Grid during the interval. The Calendar is continuously updated by the Core of the GuardTime timestamping service and continuously distributed to the GuardTime Gateways to facilitate local verification of timestamps. GuardTime started the Calendar at 01.04.2008 and has since been filling it up constantly without breaks.
- How is the Calendar related to my timestamps?
- All the GuardTime issued timestamps are registered in the Calendar through aggregate hash values. Each document that is timestamped can be related cryptographically to the aggregate hash values in the Calendar.
- What is the Calendar DB and what does it contain?
- Calendar DB contains one entry for each UTC second that represents the root hash of the global hash tree for that second. The global hash tree contains as leaf nodes the hash values of all timestamp requests received by gateways during that second. In this sense the calendar DB contains cryptographic summaries of all timestamps ever issued by the GuardTime service.
- How is time information encoded in the calendar information?
- Every aggregate hash value in the Calendar has its corresponding time encoded as an integer representing time in the Unix time_t format (i.e. the number of seconds passed since 01.01.1970 00:00:00 UTC).
- What is the time resolution of the GuardTime timestamp?
- GuardTime issues timestamps with time resolution of one second.
- Is GuardTime time traceable to UTC and how is the core time audited?
- GuardTime Calendar time is synchronized to trusted UTC time sources by means of the NTP protocol. Reference time sources are official Time Authorities in respective countries of core sites and several other Stratum-1 clocks that trace to UTC either via TA or GPS. In addition to NTP time sources GuardTime Calendar time is also kept in local atomic clocks for independent reference, stability, and anomaly detections.
GuardTime Calendar time is internally audited by regular sampling of core timing systems from independent monitoring stations that compare core time offset from independent UTC trusted time sources and log the difference to log files. These log files are also timestamped and archived.
GuardTime Calendar time can be audited by any subscriber or auditing authority with access to the GuardTime service. Time accuracy of the GuardTime Calendar system is publicly available information appearing in every timestamp reply, and any deviations can be immediately detected and brought to public attention. Accuracy of the GuardTime Calendar time can be verified without any cooperation from GuardTime and thus utmost independent auditing is possible. - If I have a timestamp that is issued before a newspaper publication, how does GuardTime guarantee the validity of the timestamp?
- A newspaper publication is a cryptographic summary of the GuardTime Calendar. A timestamp can be verified relative to either a newspaper publication or the Calendar. The timestamps that are issued before a new newspaper publication are verifiable relative to the Calendar only.
Every GuardTime Gateway hosts a Calendar that is updated in real time. For the timestamps that are issued before a newspaper publication the Calendar serves as the only reference for verification. The validity of such timestamps is guaranteed by verifying them with independently hosted Gateways. - How does GuardTime ensure accurate time?
- GuardTime uses high resolution atomic clocks. The atomic clocks are constantly monitored and corrected against a collection of Stratum 1 level clocks.
- Does GuardTime use cryptographic keys, and if so for what purposes?
- GuardTime is using cryptographic keys for authentication only. GuardTime is supplying every issued timestamp with a digital signature to provide additional assurance of correct delivery of timestamps to its customers. Importantly, long-term verification of GuardTime timestamps does not depend on keys.
