Retained-Key Encryption

Retained-Key Encryption

David Crowe (Department of Computer and Information Science, Kentucky State University, Frankfort, KY, USA) and Wasim Al-Hamdani (College of Mathematics, Sciences, Technology and Health, State University, Frankfort, KY, USA)
DOI: 10.4018/jitn.2013040101
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

This paper presents a synchronous encryption key management model that does not require the sender to disclose the encryption key in order to effect decryption. This eliminates the need for key exchange mechanisms, giving the sender improved control over their keys. The retained-key model is presented as being a software application that handles the initiation of a secure communication channel between sender and receiver, and facilitates user authentication by a trusted third party—presumably, the software’s vendor. This model is not intended to replace public/private key-based mechanisms, as they serve an important role in message signing and authentication. Rather, it seeks to provide an alternative means of decrypting messages in a secure fashion while allowing the sender to avoid the need to disclose the message’s key.
Article Preview

Introduction

Traditionally, encryption revolves around the analogy of Alice sending an encrypted message to Bob in such a way as to keep Eve from readily understanding the message should she come across a copy of it. “Key management” is the term that describes the processes used to manage cryptographic keys, and incorporates the following functions:

  • Providing an encryption key for a user or system that wants to protect data;

  • Providing the appropriate decryption key for a user or system that wants to access encrypted data;

  • Allowing an administrator to specify policies that dictate who can get which keys, how keys are recovered, and how users must authenticate (Voltage Security, 2013).

Key management, then, includes “the generation, exchange, storage, use, and substitution of keys [and] includes cryptographic protocol design, key servers, user procedures, and other relevant protocols (“Key management,” 2013). Further, managing keys is a vitally important element of any cryptosystem, and “is arguably the most difficult aspect of cryptography because it involves policy, users, business interactions—internally and externally—and co-ordination between all of these activities” (Voltage Security, n.d.)

Forms of Encryption

Broadly, there are two forms, or types, of encryption: asynchronous and synchronous. The difference between these two forms lies in the nature of the keys involved. Asynchronous encryption—which has been the standard since its introduction in the late 1970s—uses one key for encryption and a different key for decryption. This is in contrast to synchronous encryption which uses the same key for both operations.

While the two keys used in asynchronous encryption are different, they are mathematically related. One key can be “publish[ed], for all the world to see” (Perrin, 2009), but the other must always be kept secret. Commonly, the phrase “public key cryptography” is used to mean asynchronous encryption, and the two keys are called public and private respectively. The process of exchanging asynchronous keys is usually likened to keeping the message safe (encrypted) in a lockbox. Alice and Bob perform a choreographed series of exchanges until Bob eventually winds up with a locked box to which he has the key (and can then decrypt the message).

Synchronous encryption is likely to be a much more familiar cryptosystem to most users. Here, Alice writes a message and encodes it using an encryption key. She then sends the message to Bob. In order for Bob to decrypt the message, he must somehow acquire the same key (or a copy of it) that Alice used to encrypt it. The key must be sent securely to make sure Eve cannot use it to decipher the message.

One method for delivering the key to Bob is the Diffie-Hellman key exchange. Alternate scenarios describe the process as mixing paint: a one-way process that cannot be reversed. This analogy is commonly used, as it is a fair representation of the actual process. Simon Singh’s The Code Book provides one such variation where Alice and Bob mix and trade mixing pots until they both end up with pots that contain equal parts of Alice’s secret color, Bob’s secret color, and a mutually-agreed upon common color. Neither person “has [any] idea what color was added [by the other]” (as cited in Parr, 2009), but the resulting color (the decryption key) is the same.

With either form of encryption, the distribution of the key(s) can occur before, concurrently, or after the message is sent. Regardless of the timing, Bob cannot decipher the message until he has the method-proper key. The model this paper presents seeks to eliminate the need for any such distribution—or the key management processes incumbent in that distribution. The authors suggest that there is a different way to consider the problem of delivering key information so as to retain its confidentiality. The model could generally be considered synchronous, as it uses the same key for encryption and decryption. Yet the key is retained by the sender—Alice. This alteration to the normal process led to the term “retained-key” encryption.

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 10: 4 Issues (2018): 1 Released, 3 Forthcoming
Volume 9: 4 Issues (2017)
Volume 8: 4 Issues (2016)
Volume 7: 4 Issues (2015)
Volume 6: 4 Issues (2014)
Volume 5: 4 Issues (2013)
Volume 4: 4 Issues (2012)
Volume 3: 4 Issues (2011)
Volume 2: 4 Issues (2010)
Volume 1: 4 Issues (2009)
View Complete Journal Contents Listing