Some Caveats

By Larry Loeb  |  Posted 2005-10-03 Print this article Print

Some Caveats Its important to remember that the presence of a digital signature does not imply anything about the state or authenticity of the message to which it is linked. A signature links a sender to a message; it doesnt authenticate the message itself.
The message telling the Air Force to start bombing Moscow Right Now may have a correct signature; but it will not be acted upon (hopefully—see the movie "Dr. Strangelove " for more on this) until it has been authenticated by some other independent means.
The message may be left in plaintext, and thus any receiver of the message can verify that it was indeed sent by the purported sender. If the message is encrypted in some way (say with a secret key) only those possessing the key can decode the message, perform a hash operation on the plaintext to get a digest, compare the digest to the encrypted digest decoded using the senders public key and thus determine the validity of the digital signature. For now the important thing is to remember that digital signatures can work to bind someones private key (again, by being able to decrypt with the public key we consider the message to have been encrypted by the private key) to a message. Lets take signatures one step further in degree: That message can be "countersigned" by someone else (like a receiver-trusted Certificate Authority) to form what is called a certificate. Certificates are defined structurally and technically in RFC1422. This implies compliance with the X.509 v3 standard as well. Dual Signatures Dual signatures can link two messages within a message unit. These segments may be effectively addressed to differing people such that the message parts may only be read by the intended recipient, yet provide a way to check authenticity of the overall message. Lets consider how to actually do this. A dual signature is generated by creating a message digest (hash) of both plaintext messages individually (H(m1) and H(m2)), concatenating these digests into one value [m3] and then taking the hash of that value [H(m3)]. Encrypting H(m3) with the signers private key provides the dual signature. A recipient operates upon the message by first computing the message digest of the message sent, then concatenating it with the sender-provided message digest of the other message, and finally computing the result. This should equal the decrypted dual signature. Thus, dual signatures link two individual messages into one functional unit for transmission, yet will keep the information content compartmentalized. Enveloping Now, what if one part of the message needs to be more "secure" than the other? The simple way out of this situation is to apply another layer of encryption on top of the "message plus signature" data. A so-called "digital envelope "is a way to encrypt data and to send the key for that encryption along with the data. Most enveloping schemes use a symmetric method to encrypt the data, and an asymmetric one to encrypt the key. Randomness and Signatures One aspect about the mathematics of key encoding is illuminating as to how real life can intrude on the best ordered calculations. The encoding scheme needs to start its mathematical operations from some initialization vector, or random sequence of numbers, to provide the best possible security. Pseudo-random number generator (pRNG) programs can provide these initializing values, or random human actions like the time between hitting keys can be used to provide them. pRNGs have a topic of some controversy amongst the sci.crypt newsgroup, where some serious cipher-lovers hang out. The discussion consensus evolved that pRNGs work, but only up to a point. The problem is that pRNGs may also require an initial seed value to generate randomized numbers. Providing these seed numbers can be a problem for the designer. Netscape suffered some rather public embarrassment when it was discovered by an observer that the time of day was being used as a seed value in Navigator 2.0. Knowing the seed value allowed an easier computational attack on the encrypted messages that Navigator was generating. For very secure (read: military) situations, the sci.crypt folk like other types of RNGs such as physical radiation-decay emission counters. That sort of hardware is obviously impractical in the normal user universe, but it behooves the designer using encryption to consider carefully where his or her random seeds come from. Eastlake, Crocker and Shillers RFC 1750 Randomness Recommendations for Security should be consulted for further details on randomization of seeds. Chaos, in this instance, can work for you. Next page: So What Good is It?


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel