Frequently Asked Questions

If you have any questions regarding our service, please use the form below to send it to us.

Hash functions and cryptographic basics

Why does GuardTime not use a more secure hash algorithm?

There are two main reasons for this:
• There is no need to use more secure hash functions. No attacks that would affect the security of the GuardTime system are known to exist against SHA2-256 (or even against SHA-1, or MD5).
• More secure hash functions are harder to compute and have larger outputs which would make the GuardTime system more resource-consuming. For example, changing to SHA2-512 would up to double the size of the timestamp in the GuardTime system.

Can I use other hash algorithms in my application?

Users of the GuardTime system are able to choose between several hash functions for creating a timestamp request for the document they want to timestamp. Currently available choices supported by the GuardTime APIs are SHA-1, SHA2-224, SHA2-256, SHA2-384, SHA2-512, RIPEMD-160, RIPEMD-256.
The causal links between timestamp requests and the published hash codes are created internally in the GuardTime system, and therefore use hash functions selected by GuardTime. Users have no control over this choice.

If a hash algorithm is known to be compromised, can the GuardTime system switch to a stronger hash algorithm, and if so, how specifically does GuardTime do this?

GuardTime can quickly switch from one hash function to another. The internal hash function is specified in configuration files that can be changed without recompiling or reinstalling any system software.

How are older timestamps protected in the event that the GuardTime hash algorithms are compromised?

If developments in cryptanalysis of hash functions start putting existing timestamps in danger, then it is possible to re-timestamp the original document and its old timestamp with a new hash function (e.g. SHA2-384) that still remains secure.
A new timestamp on the old document proves that the document existed before the old hash function was broken. A new timestamp on the old timestamp proves that the old timestamp (that represents a chain of hashing operations with the old hash function) existed before the old hash function was broken. As a result, there is still undeniable evidence that proves the existence of the document at the date given in the old timestamp.

What are the implications (i.e. timestamp size, communications overhead, etc) of switching to a stronger hash algorithm such as SHA-512?

• Communication volume inside the GuardTime network is doubled
• The size of the timestamps is doubled
• The gateway server’s required memory size is doubled
• The load on the Gateway servers and the GuardTime internal servers is somewhat higher

GuardTime Timestamps

What is the size of the GuardTime timestamp?

The size of a GuardTime timestamp is 4 KB. Note that this does not imply that 4KB of storage is needed per event or file that needs to be timestamped. For high volume  due to the overlapping hash values between timestamps the size required for storage can be less than 100 Bytes.

What is the timestamp protocol used by GuardTime?

There are various standards for timestamping protocols, such as IETF RFC 3161, ETSI TS 102 023 v1.2.1, ISO/IEC 18014-1/2/3, and ANSI ANS X9.95. The GuardTime timestamp format is compatible with the timestamp format defined in IETF RFC 3161 except for the proprietary digital signature structure. The request and response formats for timestamping that GuardTime uses are compatible or close to compatible with all of these standards. Some of these standards suggest general solutions for implementing a Time Stamping Authority (TSA). On the TSA implementation, GuardTime is closest to ISO/IEC 18014-3 and ANSI ANS X9.95.

Are GuardTime timestamps compatible with the RFC 3161 protocol?

GuardTime timestamps are in the same format as timestamps defined in RFC 3161. However, GuardTime timestamps cannot be completely parsed with standard RFC 3161 implementations as the timestamp contains some GuardTime-specific information currently not documented in any RFC. The specifications of this GuardTime-specific information are disclosed so that anyone can develop a parser for GuardTime timestamps.

What information does my timestamp contain?

Besides the date and time of timestamp generation, the timestamp contains other information about the issuer of the timestamp (such as service name of the issuer) and a serial number assigned to the timestamp by issuer. A timestamp does not contain any information related to the timestamp request. Please refer to GuardTime for more detailed information about the timestamp format.

How do I view the contents of my timestamp?

The timestamps are encoded in ASN.1 and can be read by any ASN.1 viewer.

Does my timestamp contain all the information necessary for me to verify it? If not, what other information do I need?

In general, a timestamp by itself does not contain all the information necessary for its verification. The missing information, related to the GuardTime Calendar, resides locally in your Gateway, and GuardTime verification functions automatically retrieve this information when verifying a timestamp.
Note also that it is possible, using the API functions, to place into existing timestamps all the necessary information to be able to verify a timestamp with only the timestamp itself and the original timestamped document.

Privacy and security

If I host my own Gateway, what security issues should I be concerned about?

Hosting a GuardTime Gateway is similar to hosting any Linux server. Usual systems management practices apply. The only necessary externally visible service is the lighttpd web server daemon. If the Client is providing a service over the Internet then it is recommended to host the Gateway in a DMZ environment.
There is no confidential information stored in Gateways, except configuration files with access parameters.
Additionally, there are multiple ways to limit client access to the GuardTime Gateway. As the service is run over the HTTP protocol all web authentication methods can be used. The following are some examples:
• Using an appropriate network topology, for example putting the Gateway into an internal network so that only LAN users can access it.
• Using basic authentication. For setup it is recommended to refer to the lighttpd documentation. Also, in basic authentication cases passwords are sent over the network without encryption, thus SSL/TLS tunneling is recommended. In this case the Gateway address can be specified in the form of https://name:password@gwaddr/service in the GuardTime API.
• Using authentication with an SSL/TLS client certificate.
• Using client IP address limitation. This could be done through lighttpd web server configuration, Linux host firewall configuration or using some external means.

What if someone modifies the timestamp request/response?

In case of data tampering (modifying the timestamp request or response) the timestamping system returns error and the timestamp will not be formed nor verified.
The timestamp request and response data, when transferred within the GuardTime Grid, is protected by using keyed HMAC code; in case of tampering a redundant path is chosen transparently.
Timestamp requests and responses between the client application and the Gateway are protected by a GuardTime signature on the timestamp data; when a timestamp is received from the Gateway, it will be fully verified. In case of any problems an error is reported and the received invalid timestamp is thrown away. It is the responsibility of the client application to request a new timestamp in case of any error.

Verification

How does GuardTime guarantee that the verification process or tool is correct?

The correctness of the verification process relies on a mathematical proof of individual steps required to reach the conclusion. After all efforts of finding the fault in the process have failed, it is reasonable to assume that the verification process is correct, until proven otherwise.
Source code for verification tools is provided to every interested party in order to make possible an independent quality audit of the code. Considerable effort is made to guarantee that the implementation, support libraries, and coding styles do not weaken the reliability of the results. Correctness of the tools is warranted by the inability to find a fault in them.