diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt | 244 |
1 files changed, 0 insertions, 244 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt b/crypto/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt deleted file mode 100644 index 4dcff48..0000000 --- a/crypto/heimdal/doc/standardisation/draft-horowitz-key-derivation-01.txt +++ /dev/null @@ -1,244 +0,0 @@ -Network Working Group M. Horowitz -<draft-horowitz-key-derivation-01.txt> Cygnus Solutions -Internet-Draft March, 1997 - - - Key Derivation for Authentication, Integrity, and Privacy - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow - Directories on ds.internic.net (US East Coast), nic.nordu.net - (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific - Rim). - - Distribution of this memo is unlimited. Please send comments to the - author. - -Abstract - - Recent advances in cryptography have made it desirable to use longer - cryptographic keys, and to make more careful use of these keys. In - particular, it is considered unwise by some cryptographers to use the - same key for multiple purposes. Since most cryptographic-based - systems perform a range of functions, such as authentication, key - exchange, integrity, and encryption, it is desirable to use different - cryptographic keys for these purposes. - - This RFC does not define a particular protocol, but defines a set of - cryptographic transformations for use with arbitrary network - protocols and block cryptographic algorithm. - - -Deriving Keys - - In order to use multiple keys for different functions, there are two - possibilities: - - - Each protocol ``key'' contains multiple cryptographic keys. The - implementation would know how to break up the protocol ``key'' for - use by the underlying cryptographic routines. - - - The protocol ``key'' is used to derive the cryptographic keys. - The implementation would perform this derivation before calling - - - -Horowitz [Page 1] - -Internet Draft Key Derivation March, 1997 - - - the underlying cryptographic routines. - - In the first solution, the system has the opportunity to provide - separate keys for different functions. This has the advantage that - if one of these keys is broken, the others remain secret. However, - this comes at the cost of larger ``keys'' at the protocol layer. In - addition, since these ``keys'' may be encrypted, compromising the - cryptographic key which is used to encrypt them compromises all the - component keys. Also, the not all ``keys'' are used for all possible - functions. Some ``keys'', especially those derived from passwords, - are generated from limited amounts of entropy. Wasting some of this - entropy on cryptographic keys which are never used is unwise. - - The second solution uses keys derived from a base key to perform - cryptographic operations. By carefully specifying how this key is - used, all of the advantages of the first solution can be kept, while - eliminating some disadvantages. In particular, the base key must be - used only for generating the derived keys, and this derivation must - be non-invertible and entropy-preserving. Given these restrictions, - compromise of one derived keys does not compromise the other subkeys. - Attack of the base key is limited, since it is only used for - derivation, and is not exposed to any user data. - - Since the derived key has as much entropy as the base keys (if the - cryptosystem is good), password-derived keys have the full benefit of - all the entropy in the password. - - To generate a derived key from a base key: - - Derived Key = DK(Base Key, Well-Known Constant) - - where - - DK(Key, Constant) = n-truncate(E(Key, Constant)) - - In this construction, E(Key, Plaintext) is a block cipher, Constant - is a well-known constant defined by the protocol, and n-truncate - truncates its argument by taking the first n bits; here, n is the key - size of E. - - If the output of E is is shorter than n bits, then some entropy in - the key will be lost. If the Constant is smaller than the block size - of E, then it must be padded so it may be encrypted. If the Constant - is larger than the block size, then it must be folded down to the - block size to avoid chaining, which affects the distribution of - entropy. - - In any of these situations, a variation of the above construction is - used, where the folded Constant is encrypted, and the resulting - output is fed back into the encryption as necessary (the | indicates - concatentation): - - K1 = E(Key, n-fold(Constant)) - K2 = E(Key, K1) - - - -Horowitz [Page 2] - -Internet Draft Key Derivation March, 1997 - - - K3 = E(Key, K2) - K4 = ... - - DK(Key, Constant) = n-truncate(K1 | K2 | K3 | K4 ...) - - n-fold is an algorithm which takes m input bits and ``stretches'' - them to form n output bits with no loss of entropy, as described in - [Blumenthal96]. In this document, n-fold is always used to produce n - bits of output, where n is the key size of E. - - If the size of the Constant is not equal to the block size of E, then - the Constant must be n-folded to the block size of E. This number is - used as input to E. If the block size of E is less than the key - size, then the output from E is taken as input to a second invocation - of E. This process is repeated until the number of bits accumulated - is greater than or equal to the key size of E. When enough bits have - been computed, the first n are taken as the derived key. - - Since the derived key is the result of one or more encryptions in the - base key, deriving the base key from the derived key is equivalent to - determining the key from a very small number of plaintext/ciphertext - pairs. Thus, this construction is as strong as the cryptosystem - itself. - - -Deriving Keys from Passwords - - When protecting information with a password or other user data, it is - necessary to convert an arbitrary bit string into an encryption key. - In addition, it is sometimes desirable that the transformation from - password to key be difficult to reverse. A simple variation on the - construction in the prior section can be used: - - Key = DK(n-fold(Password), Well-Known Constant) - - The n-fold algorithm is reversible, so recovery of the n-fold output - is equivalent to recovery of Password. However, recovering the n- - fold output is difficult for the same reason recovering the base key - from a derived key is difficult. - - - - Traditionally, the transformation from plaintext to ciphertext, or - vice versa, is determined by the cryptographic algorithm and the key. - A simple way to think of derived keys is that the transformation is - determined by the cryptographic algorithm, the constant, and the key. - - For interoperability, the constants used to derive keys for different - purposes must be specified in the protocol specification. The - constants must not be specified on the wire, or else an attacker who - determined one derived key could provide the associated constant and - spoof data using that derived key, rather than the one the protocol - designer intended. - - - - -Horowitz [Page 3] - -Internet Draft Key Derivation March, 1997 - - - Determining which parts of a protocol require their own constants is - an issue for the designer of protocol using derived keys. - - -Security Considerations - - This entire document deals with security considerations relating to - the use of cryptography in network protocols. - - -Acknowledgements - - I would like to thank Uri Blumenthal, Hugo Krawczyk, and Bill - Sommerfeld for their contributions to this document. - - -References - - [Blumenthal96] Blumenthal, U., "A Better Key Schedule for DES-Like - Ciphers", Proceedings of PRAGOCRYPT '96, 1996. - - -Author's Address - - Marc Horowitz - Cygnus Solutions - 955 Massachusetts Avenue - Cambridge, MA 02139 - - Phone: +1 617 354 7688 - Email: marc@cygnus.com - - - - - - - - - - - - - - - - - - - - - - - - - - -Horowitz [Page 4] |
