Server-based signatures

In <a href="/facts/Cryptography/e94PEVau">cryptography</a>, server-based signatures are <a href="/facts/Digital_signature/tY7e2pnW">digital signatures</a> in which a publicly available server participates in the signature creation process. This is in contrast to conventional digital signatures that are based on <a href="/facts/Public-key_cryptography/gowoFTxS">public-key cryptography</a> and <a href="/facts/Public-key_infrastructure/7fwMLxF4">public-key infrastructure</a>. With that, they assume that signers use their personal <a href="/facts/Trusted_computing_base/QFA4q830">trusted computing bases</a> for generating signatures without any communication with servers.
Four different classes of server based signatures have been proposed:
1. Lamport One-Time Signatures. Proposed in 1979 by <a href="/facts/Leslie_Lamport/jGCarz9C">Leslie Lamport</a>. <a href="/facts/Lamport_signature/TGCfcYhx">Lamport one-time signatures</a> are based on <a href="/facts/Cryptographic_hash_functions/cuxkgbST">cryptographic hash functions</a>. For signing a message, the signer just sends a list of hash values (outputs of a hash function) to a publishing server and therefore the signature process is very fast, though the size of the signature is many times larger, compared to ordinary public-key signature schemes.
2. On-line/off-line Digital Signatures. First proposed in 1989 by <a href="/facts/Shimon_Even/urvDI0vA">Even</a>, <a href="/facts/Oded_Goldreich/Ufn1bqW7">Goldreich</a> and <a href="/facts/Silvio_Micali/IxgCplaX">Micali</a> in order to speed up the signature creation procedure, which is usually much more time-consuming than verification. In case of <a href="/facts/RSA_cryptosystem/XTzyfHuq">RSA</a>, it may be one thousand times slower than verification. On-line/off-line digital signatures are created in two phases. The first phase is performed <a href="/facts/Online_and_offline/rhxAKfol">off-line</a>, possibly even before the message to be signed is known. The second (message-dependent) phase is performed on-line and involves communication with a server. In the first (off-line) phase, the signer uses a conventional public-key digital signature scheme to sign a public key of the Lamport one-time signature scheme. In the second phase, a message is signed by using the Lamport signature scheme. Some later works 
 have improved the efficiency of the original solution by Even et al.
3. Server-Supported Signatures (SSS). Proposed in 1996 by <a href="/facts/N._Asokan/rsmEuICa">Asokan</a>, <a href="/facts/Gene_Tsudik/oFpj0mEp">Tsudik</a> and <a href="/facts/Michael_Waidner/hpYe5J6J">Waidner</a> in order to delegate the use of time-consuming operations of <a href="/facts/Asymmetric_cryptography/gowoFTxS">asymmetric cryptography</a> from clients (ordinary users) to a server. For ordinary users, the use of asymmetric cryptography is limited to signature verification, i.e. there is no pre-computation phase like in the case of on-line/off-line signatures. The main motivation was the use of low-performance mobile devices for creating digital signatures, considering that such devices could be too slow for creating ordinary public-key digital signatures, such as <a href="/facts/RSA_Cryptosystem/XTzyfHuq">RSA</a>. Clients use <a href="/facts/Hash_chain/B0HUMdkM">hash chain</a> based <a href="/facts/Authentication/64y4S69b">authentication</a> to send their messages to a signature server in an <a href="/facts/Authentication/64y4S69b">authenticated</a> way and the server then creates a digital signature by using an ordinary public-key <a href="/facts/Digital_signature/tY7e2pnW">digital signature</a> scheme. In SSS, signature servers are not assumed to be <a href="/facts/Trusted_third_party/VdPm949G">Trusted Third Parties</a> (TTPs) because the transcript of the hash chain authentication phase can be used for <a href="/facts/Non-repudiation/uNAP1YIf">non repudiation</a> purposes. In SSS, servers cannot create signatures in the name of their clients.
4. Delegate Servers (DS). Proposed in 2002 by Perrin, Bruns, Moreh and Olkin in order to reduce the problems and costs related to individual <a href="/facts/Private_key/gowoFTxS">private keys</a>. In their solution, clients (ordinary users) delegate their private cryptographic operations to a Delegation Server (DS). Users authenticate to DS and request to sign messages on their behalf by using the server's own private key. The main motivation behind DS was that private keys are difficult for ordinary users to use and easy for attackers to abuse. Private keys are not memorable like <a href="/facts/Password/WEoul230">passwords</a> or derivable from persons like <a href="/facts/Biometrics/MgTbyA0r">biometrics</a>, and cannot be entered from <a href="/facts/Keyboard_(computing)/MczF9LIS">keyboards</a> like passwords. Private keys are mostly stored as <a href="/facts/Computer_file/FjFH3Ufm">files</a> in <a href="/facts/Computer/SQe1aK05">computers</a> or on <a href="/facts/Smart-card/K7b9lowS">smart-cards</a>, that may be stolen by attackers and abuse off-line. In 2003, Buldas and Saarepera proposed a two-level architecture of delegation servers that addresses the trust issue by replacing trust with threshold trust via the use of <a href="/facts/Threshold_cryptosystem/4KKvNxW8">threshold cryptosystems</a>.

Server-based signatures open-in-new

Server-based signatures