User:Davidgothberg/Crypto steps
This text is intended to become a subsection of the article secure channel or cryptographic protocol. Originally it was just intended as a short description of what methods are used for an encrypted session but the text kind of kept growing once I got started. I hope it is not too detailed now.
By the way, the reason I have put "compression" in the beginning of the text is that I wanted to start with something simple. To make the reader feel comfortable before we get into all the messy key stuff... But I am not sure about the placement, perhaps it should be moved to right before MACing.
A secure channel example
Cryptographic systems and cryptographic protocols usually apply several steps when creating a secure channel or an encrypted message. This text briefly describes these steps (layers) and the order they are applied. These steps are more or less the same both for encrypted files on disk or encrypted streams (connections) over the Internet or some other channel. Note that this is not a complete description but only an overview.
The usual steps when encrypting a file is:
- Write the protocol header
- Make and write the IV
- Do key set-up
- Compress the message
- Sign or MAC to the message
- Encrypt the message and write the encrypted message
The usual steps in an encrypted communication session is something like this:
- Protocol negotiation
- Exchange of IVs
- Key negotiation
- Key set-up
- Compress the message
- Sign or MAC to the message
- Encrypt the message and send the encrypted message
Note that "+" in this article means string concatenation. Thus "A" + "B" = "AB".
Compression
Before the message is encrypted it is often compressed.
The main reason is to make the message smaller to save storage space / bandwidth. Since after the message has been encrypted the message can not be compressed anymore, so it has to be done before if it should be done. (If it can be compressed after encrypting it the encryption used is very very bad.)
Since the compression makes the data smaller it gives an attacker less data to analyse which is a good thing.
The compression also to some extent work as "whitening" of the message. That is, it makes the data look more like random white noise and thus makes cryptanalysis (cracking) of the message harder. However most modern cryptos have built in whitening or use block cipher modes that do whitening.
Key agreement
Before two parties can communicate securely they need to agree on a key to use (a shared secret).
( Links that might be relevant in this section: Key (cryptography), Key management, Key exchange, Public-key cryptography, Man in the middle attack )
IV / nonce
For simplicity the same shared secret (key) is often used for several sessions / messages. However, using the same key for several messages is not a good thing. Therefore an IV (initialization vector / nonce) is usually added. The IV should be unique (as in never reused) for each message and the IV is in some way combined with the shared secret to make the encryption of each message unique.
The IV can either be a counter which gives a new counter value for each message or it can be a big random value (a nonce) that is big enough (at least 8 bytes) that it is very unlikely that the same IV will ever be used again. A random IV might be simpler to use and more secure then a counter (no risk of loosing count and reusing an old counter value).
There are many ways that the IV and key can be combined to make each message unique. Many of the block cipher modes include the "mixing in" of the IV in their mode. Some other ways to combine IV + key is:
session key = IV + shared secret session key = hash( IV + shared secret )
Hashing together the IV and the shared secret is the most secure method and is also more secure then the IV mixing in most block cipher modes. The main reason is that if an attacker finds out one session key (for instance by cracking one message such that he finds out the session key) then he still can not find out the shared secret and the other session keys. Since that would involve calculating the hash backwards, which should be "impossible".
Normally the IV does not need to be kept secret and the receiver needs to learn the IV to be able to decrypt the message. Thus the IV is often sent/stored in cleartext right before the encrypted message.
Making many keys
Often one file or one stream (connection) consists of several messages that is encrypted and MACed separately. This means each file or stream often needs several keys for both encryption and MACing of messages. This problem is more or less the same as making many session keys. There are several ways to make many keys out of one session key, most work something like this:
message key = hash( session key + message counter )
This means that the whole file or connection only needs to contain/send one IV for the whole session since a counter is used to make unique keys for each message. Note that in this case using a counter is simple and secure since during a single session there is usually no risk of loosing count and reusing an old counter value. The message counter is often available "for free" since the system often counts messages for other reasons too. This also adds the benefit that no extra space/bandwidth is needed for an IV for each message.
This method is also used to make different keys for encryption and for MACing and for making different keys for the two different directions in a communication session.
Hashing together a key and a counter like this to create multiple output creates a kind of cryptographically secure pseudo-random number generator (secure PRNG). Other kinds of secure PRNGs can also be used to create multiples message keys from one session key. Then the session key is used as the PRNG seed.
Message Authentication Code (MAC)
Secure messaging is not only about confidentiality (making messages unreadable to an attacker). Integrity is important too. That is, that no one can manipulate or sabotage the message while in storage or in transit.
To discover if a message is accidentally damaged a checksum or hash of the message can be added to the message. But an attacker can often manipulate the message in such a way that the checksum still looks ok, even if the message is encrypted. So to protect against malicious manipulation a MAC (Message Authentication Code) should be used.
A MAC can for instance be a keyed hash and basically works like this:
MAC = hash( key + message )
Often a more advanced (more secure) form of keyed hash is used like for instance the HMAC. There are also ways to use block cryptos efficiently to make MACs. OMAC and PMAC are such MACs.
The output of the MAC is sent along with the message so the receiver can check that the message has not been altered/damaged.
MACing can be done before or after the encryption of the message. Both alternatives are secure. If the MAC is done outside the encryption it can also include/protect any non-encrypted headers in the message.
MACing can also be used for non-encrypted messages to provide strong integrity even without confidentiality.
Encryption
Each message should be encrypted with a unique key or a combination of a key and a unique IV. When using block cryptos a secure block mode needs to be used. ECB is not a secure block mode but CBC and CTR mode is.
Extended methods
There are several ways to combine methods in cryptography to create an even higher level of security. Some consider this paranoid, some consider it prudent.
Combining different keys
To reduce the risk that the shared secret is compromised it can be made from key material from several sources. For instance a passphrase known by both users, a key delivered on a diskette by a trusted courier and a key negotiated using public keys. Combining the keys can of course be done like this:
shared secret = hash( key1 + key2 + key3 )
Combining different cryptos
Since we can never know if the attacker has cracked some certain cryptographic algorithm it might be prudent to use several different cryptos on top of each other. Preferably cryptos of very different types should be used since the new attack might crack several cryptos of the same type. Note that for each crypto a separate unrelated key should be used. Since if the same key is used for all layers and the attacker cracks the outermost crypto such that he figures out the key he then would know the key for the inner layers too. "Unrelated" keys can be made the same way as when making multiple message keys from one session secret.
Combining different hashes
Since we can never know if a specific hash method has been compromised it might be wise to combine several different hashing algorithms when doing hashing, making keys and making MACs. Combining several hashes in a secure way so that one compromised hash does not compromise the whole system is a bit tricky.
For instance the Transport Layer Security protocol combines MD5 and SHA-1 when making multiple message keys. Note that both these hashing algorithms have been partially compromised (in 2004 and 2005) but hopefully the combination is still secure.