Deploying, Implementing and Using Cryptographic Systems
From Telecomix Crypto Munitions Bureau
This entry is subject to revision. It's not a complete guide, but some observations and advice that might assist people in deploying reliable cryptographic systems.
Contents |
[edit] Choosing Encryption
One of the most important considerations when choosing the cryptosystem is whether it's open source or proprietary/closed. Kerckhoff's principle is a general rule that states the encrypted plaintext must remain unrecoverable by a third party in posesion of the encryption algorithm and the ciphertext. In other words, the security of a cryptographc system should depend entirely on the private key while the algorithm is publicly known.
The best cryptographic system is usually open source, widely used, and inspected/audited over a considerable period by many programmers, experts and academics. Such cryptographic systems have become trusted after withstanding much critical examination and many attempts to find weaknesses. Algoritms that are kept secret aren't open to the same level of examination, so they might contain vulnerabilities the creators themselves are unaware of. To quote Bruce Schneier and Niels Ferguson: 'As consultants, we have analysed quite a number of secret encryption algorithms, and all of them were weak.' (Practical Cryptography) Proprietary/closed systems could also have a backdoor that allows governments and law enforcement agencies to reverse or remove the encryption, and this adds another serious flaw in the security, since encryption should be designed to prevent this kind of access.
[edit] Passwords
Encryption keys are often derived from passwords, either by turning them into a keystream or by hashing them. This means bruteforce attacks aren't necessarily used to determine the password itself, but to find something that results in the same output when hashed. The particular algorithm is another consideration, and ideally we want one that's proven non-reversible and resistant to collision attacks. Below we can compare the different sizes of the hash values for the MD5 and SHA256 algorithms:
md5sum thepassword.txt = 3c41ff681c1e3dcb68b4d8573bf1c74c sha256sum thepassword.txt = 85d8fa8fa6bdd3db050005b44ec3c5302b389ced054ec7d59eac2edba2251946
As we can see, SHA256 generates a value twice as long, and therefore a much lower probability of an attacker generating the same hash value as the password. The probability of a random input producing a given hash value is approximately 1 in 123,000,000,000,000,000,000,000,000.
[edit] HTTPS and Secure Connection Issues
In theory https provides a secure connection between the client and the server, and is particularly useful when the client is sharing the same Local Area Network with many other hosts, which is usually the case when using any public network, WiFi service, workplace computer, etc. A good policy is to use https wherever possible, and there are Firefox extensions that do this. However, man-in-the-middle attacks are still possible in which the secure connection is between the client and a host intercepting and relaying the traffic. Server certificates can provide some assurance the client has indeed connected to the intended server, and it's important to check this before sending any sensitive information. A secure https connection doesn't provide anonymity, since only the payload is encrypted. The packet header containing the source and destination addresses are still readable to other hosts between the client and server.
[edit] Key Management
We're often told not to use the same password for more than one service, so many of us end up with a collection of them. One solution is to store them in an encrypted database, and there are a number of products available that do this.
[edit] Memory
When we're using encryption, the decrypted data and the private key must be stored somewhere, and that's usually in the system memory (RAM). Some badly developed cryptosystems will allow this to be moved to the swap partition where it can potentially be recovered later using forensic methods. This is the case for both magnetic and solid state storage. On the other hand, a well-designed cryptosystem will protect the memory location from being accessed by unauthorised programs, and also prevent it being swapped out. A possible solution is to encrypt the swap partition with a randomly generated key at every boot. Another point to remember is system memory (RAM) isn't as volatile as less technical literature claims. The diodes in RAM retain their states for a considerable period after power is removed, depending on environmental factors. Some contents of system memory are recoverable if the computer is rebooted within that period.
[edit] Cryptography and the Cloud
Another consequence of trusting proprietary encryption is back doors may be present, which allow third-parties to access the information. There are dangers in using a back-doored cryptosystem - it allows third-party access which cryptography is supposed to prevent, it doesn't guard against corruption or incompetence within government/law enforcement, and the backdoor considerably weakens the cryptosystem. Those possibilities, in my opinion, make the cryptosystem worthless. This may be the case with most online storage providers, so we must encrypt the data prior to uploading it.
Choose the online storage provider carefully, and read the privacy statement until it can be determined who exactly has access to the account.
