Key management: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
(create as redirect, might be spearate article later)
 
imported>Sandy Harris
(redirect -> article, initial text moved from cryptography article)
Line 1: Line 1:
#REDIRECT [[Key (cryptography)]]
{{subpages}}
 
Even an excellent safe cannot protect against a thief who knows the combination. Even an excellent [[cipher]] cannot protect against an enemy who knows the [[Key (cryptography) | key]].
 
Many cryptography|cryptographic]] techniques — [[block cipher]]s, [[stream cipher]]s, [[public key]] encryption, [[digital signature]]s, and [[hashed message authentication code]]s — depend on [[cryptographic key]]s. '''None of these can be secure if the key is not.''' Enemies can sometimes read encrypted messages without breaking the cipher; they use [[Cryptanalysis#Practical_cryptanalysis | practical cryptanalysis]] techniques such as breaking into an office to steal keys.
 
The ''size'' and the ''quality'' of keys are almost as important as their secrecy. Keys need to be '''large enough''' and '''highly random'''; those two properties together make them effectively impossible to guess. A key that an enemy can easily guess, or that he can find with a low-cost search, does not provide much protection. Using strong cryptography with a poor key is like buying good locks then leaving the key under the doormat. See [[cryptographic key]] and [[random number generator]] for details.
 
In applications which encrypt a large volume of data, '''any cipher must be re-keyed from time to time''' to prevent an enemy from accumulating large amounts of data encrypted with a single key. Such a collection facilitates some attacks — see [[code book attack]], [[linear cryptanalysis]] and [[differential cryptanalysis]] in particular, and [[cryptanalysis]] in general. ''It also makes the payoff for breaking that key very large''. Re-keying also limits the damage if a key is compromised in some other way. Ciphers generally do not include a re-keying mechanism; some higher-level protocol manages that and re-keys the cipher using the normal keying mechanism.
 
In some applications, there are natural breaks where a new '''session key''' should be used. For example it is natural to use a different key for each new message in a message-oriented protocol such as email, or for each new connection in a connection-oriented protocol such as [[SSH]] for secure remote login. This may be all the re-keying required. Or it may not; what if some users send multi-gigabyte emails or stay logged in for months?
 
In other applications, a mechanism for periodic re-keying is required.  For a [[VPN]] connection between two offices, this would normally be the [[Internet Key Exchange]] protocol which negotiates new session keys from time to time. For an embassy, it might be a clerk who changes the key daily and an officer who delivers more keys once a month, flying in with a briefcase handcuffed to his wrist.
 
There are many ways to manage keys, ranging from physical devices and [[smartcard]]s to cryptographic techniques such as [[Diffie-Hellman]]. In some cases, an entire [[public key infrastructure]] may be involved.

Revision as of 10:45, 26 March 2010

This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Even an excellent safe cannot protect against a thief who knows the combination. Even an excellent cipher cannot protect against an enemy who knows the key.

Many cryptography|cryptographic]] techniques — block ciphers, stream ciphers, public key encryption, digital signatures, and hashed message authentication codes — depend on cryptographic keys. None of these can be secure if the key is not. Enemies can sometimes read encrypted messages without breaking the cipher; they use practical cryptanalysis techniques such as breaking into an office to steal keys.

The size and the quality of keys are almost as important as their secrecy. Keys need to be large enough and highly random; those two properties together make them effectively impossible to guess. A key that an enemy can easily guess, or that he can find with a low-cost search, does not provide much protection. Using strong cryptography with a poor key is like buying good locks then leaving the key under the doormat. See cryptographic key and random number generator for details.

In applications which encrypt a large volume of data, any cipher must be re-keyed from time to time to prevent an enemy from accumulating large amounts of data encrypted with a single key. Such a collection facilitates some attacks — see code book attack, linear cryptanalysis and differential cryptanalysis in particular, and cryptanalysis in general. It also makes the payoff for breaking that key very large. Re-keying also limits the damage if a key is compromised in some other way. Ciphers generally do not include a re-keying mechanism; some higher-level protocol manages that and re-keys the cipher using the normal keying mechanism.

In some applications, there are natural breaks where a new session key should be used. For example it is natural to use a different key for each new message in a message-oriented protocol such as email, or for each new connection in a connection-oriented protocol such as SSH for secure remote login. This may be all the re-keying required. Or it may not; what if some users send multi-gigabyte emails or stay logged in for months?

In other applications, a mechanism for periodic re-keying is required. For a VPN connection between two offices, this would normally be the Internet Key Exchange protocol which negotiates new session keys from time to time. For an embassy, it might be a clerk who changes the key daily and an officer who delivers more keys once a month, flying in with a briefcase handcuffed to his wrist.

There are many ways to manage keys, ranging from physical devices and smartcards to cryptographic techniques such as Diffie-Hellman. In some cases, an entire public key infrastructure may be involved.