# Some Caveats

**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.

**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?**

Loading Comments...