Stefan Lucks -- some papers Last modified: May 30, 1997. --------------------------------------------------------------------------- Note: Copying files for appeared papers may violate copyrights held by the publishers! Such files are marked (*) below. --------------------------------------------------------------------------- Open Key Exchange: How to Defeat Dictionary Attacks Without Encrypting Public Keys (47 K of gnu-zipped PostScript) Classical cryptographic protocols based on shared secret keys often are vulnerable to key-guessing attacks. For security, the keys must be strong, difficult to memorize for humans. Bellovin and Merritt (1992) proposed \equote{encrypted key exchange} (EKE) protocols, to frustrate key-guessing attacks. EKE requires the use of asymmetric cryptosystems and is based on encrypting the public key, using a symmetric cipher. In this paper, a novel way of key exchange is presented, where public keys are sent openly, not encrypted. In contrast to EKE protocols, the same public-key/secret-key pair can be used for arbitrary many protocol executions. The RSA-based protocol variant is found to be quite efficient and practical. Compared to previous work on such protocols, a more solid formal treatment is given, influenced by the work of Bellare and Rogaway (1993) on key exchange protocols for strong common secrets. On the Security of Remotely Keyed Encryption (50 K of gnu-zipped PostScript) The purpose of remotely keyed encryption is to efficiently realize a secret-key block cipher by sharing the computational burden between a fast untrusted device and a slow device trusted with the key. This paper deals with how to define the security of remotely keyed encryption schemes. Since the attacker can take over the slow device and actually take part in the encryption process, common definitions of the security of block ciphers have to be reconsidered. Using random mappings, collision resistant hash functions, and stream ciphers as building blocks, the Random Mapping based Remotely Keyed (RaMaRK) encryption scheme is proposed. Also GRIFFIN is proposed, a fast new block cipher for flexible but large blocks. The RaMaRK scheme and GRIFFIN are provably secure if the underlying building blocks are secure. BEAST: A fast block cipher for arbitrary blocksizes(*) (47 K of gnu-zipped PostScript) This paper describes BEAST, a new blockcipher for arbitrary size blocks. It is a Luby-Rackoff cipher and fast when the blocks are large. BEAST is assembled from cryptographic hash functions and stream ciphers. It is provably secure if these building blocks are secure. For smartcard applications, a variant BEAST-RK is proposed, where the bulk operations can be done by the smartcard's host without knowing the key. Only fast key-dependent operations remain to be done by the smartcard. Faster Luby-Rackoff Ciphers (61 K of gnu-zipped PostScript) This paper deals with a generalization of Luby's and Rackoff's results (Luby and Rackoff, 1988) on the construction of block ciphers and their consequences for block cipher implementations. Based on dedicated hash functions, block ciphers are proposed which are more efficient and operate on larger blocks than their original Luby-Rackoff counterparts. How Traveling Salespersons Prove Their Identity (37 K of gnu-zipped PostScript) In this paper a new identification protocol is proposed. Its security is based on the Exact Traveling Salesperson Problem (XTSP). The XTSP is a close relative of the famous TSP and consists of finding a Hamiltonian circuit of a given length, given a complete directed graph and the distances between all vertices. Thus, the set of tools for use in public-key cryptography is enlarged. How to Exploit the Intractability of Exact TSP for Cryptography (34 K of gnu-zipped PostScript) We outline constructions for both pseudo-random generators and one-way hash functions. These constructions are based on the exact TSP (XTSP), a special variant of the well known traveling salesperson problem. We prove that these constructions are secure if the XTSP is infeasible. Our constructions are easy to implement, appear to be fast, but require a large amount of memory. --------------------------------------------------------------------------- Back to homepage of Stefan Lucks This Web page is HTML 2.0 Checked and [Lynx Friendly!]