|
Linux Special Interest Group
...December 17th 2002 Meeting... |
|
Linux Special Interest Group
...December 17th 2002 Meeting... |
Home |Past Meetings |Links |Map |Members' Notes |Electronic Freedom Foundation |Lessons in Linux |About
One more plea for support for the Electronic Frontier Foundation to head off the Hollywood suits, Software Moguls,
and Publishers who are trying to lock up copyright and "Digital Rights Management"
in ways that could destroy the Open Source Movement, Linux, and the Internet. The least we could do AND EVERY ONE OF US SHOULD DO SOMETHING is to join
the Electronic Frontier Foundation to become better informed
AND MAKE A CONTRIBUTION to help them continue the fight for our freedom!
Will Wilgus gave us a wake-up call on encryption
by showing us the inherent vulnerabilities of ANY encryption systems in use today
or in the likely future. Clever programmers are beaten by faster computers and smarter crackers, so the situation is
constantly in flux. Appropriate to our group, he said opensource (i.e. Linux Mozilla) encryption with careful usage gives us
the best chance of at least knowing where we stand.
With awesome erudition, Will traced the history of encryption from the Persian Wars to the present. Claude Shannon (father of Information Theory) proved the ONLY unbreakable encryption method is the one-time pad, but it is unbreakable
only in principle because: (1) sender and receiver must exchange the encryption key, making it vulnerable to theft or interception; (2) the key
must be truly random, and no known method will produce a truly random key; (3) the key must be the same length as the text (try
that on the Encyclopedia Britannica!); and (4) each key can be used only once. The Russians started using one-time pads in the 1920's after British
politicians made public Soviet stuff obviously resulting from decrypted intercepts. Then they blew it in WWII by lazily re-using some of their key
material.
The recent development of Public Key Encryption (RSA) avoids some of these problems, but introduced others. Any sender can use
the public key, but only the receiver can de-crypt a message using his private key which is never disclosed. But encryption strength
is a function of the length of the key (which is a product of two prime numbers, from which the public key private keys can be mathematically derived)
as well as upon the cleverness of the
encryption algorithm. Key length of 40 bits is child's play to break, and even so-called 'strong encryption' of 128 bits is vulnerable
especially if used with a naive or compromised algorithm
The reason for avoiding proprietary encryption systems is that one has no assurance that the key-length is as advertized and
that the algorithm is clever and uncompromised, and that there is no secret back-door for the benefit of the government,
Microsoft, or a malicious coder in the vendor's company. Even the much-trusted Verisign has serious vulnerabilities, since their
system of issuing certificates is naive, and they have no mechanism for revoking one which has been shown to be fraudulent!
So what can we do? Stick to opensource encryption (Linux Mozilla), keep in touch with the opensource community to track changes
in the situation.
Will just sent (1/14/2003) a rich collection of further information related to his presentation (25 txt and rtf files including
some of the slides that were illegible in the projector and a good bibliography on encryption). He assures me they have been screened
for viruses, and I have put them on our web site: go to "Encryption".
He addresses the problem of what to do in more detail than I did above as follows:
"There was some comment on the lack of recommendations for what folks should do at the presentation. Partially this was due to the ad hoc nature of the talk and partially it was deliberate. Everyone's situation is different both in principle and in detail. What is to be protected varies from one person to another, one machine to another, and from one time to another. An attorney (or other professional) may have legal obligations to keep client information secure. Non-attorneys might not want their Quicken files (with their financial information, tax return stuff, ...) spread around. Others may want to keep information about amatory adventures secure. Different degrees of effort (time, money, learning about
1) use ONLY publicly known and unbroken encryption/message digest algorithms with key lengths sufficient to make brute force search infeasible by anyone.
2) use only publicly known and unbroken protocols (eg, for digital signatures or time stamping)
3) trust ONLY sources of information that YOU (not your consultant or anyone else) have explicitly decided are worthy of trusting the security of your information to. This specifically includes any use of "digital certificates" from any source, including any recommended by Microsoft, your uncle the Earl of Dartmouth, or your dog. That "everyone else" trusts
4) use only crypto systems which manage (store, generate, use) keys very very carefully. Where are they stored on disk (if at all), how are they sent from here to there (if they are), ... ANY slop in this aspect of crypto system operation makes perfect choices (for all the other points here) pointless.
5) use only crypto systems which randomly generate keys (this is a hard problem and there are no good solutions) and which generate them on your site. NEVER accept any vendor that "streamlines" key generation in the interest of your or anyone's convenience.
6) use only crypto systems that run on secure operating systems. This is LARGE qualification, but a necessary one. If the key you supply to the crypto system is available to others through the local version of the ps command, or if the OS keeps it in the swap file, or ... It won't take all that much for an attack on the OS to subvert your crypto system.
7) use only crypto systems running on OS which are properly and securely installed, configured, and maintained. Not the same point as 7, but related.
8) use only crypto systems which have no whiff of snake oil about them.
9) always (ALWAYS -- no exceptions) use the crypto system you get properly. This means you (and all other users of it) must understand what proper use is, and do it. This means mastering some not so obvious things (reading the manual might be the first, sorry about that) and if the documentation is incompetent, incomplete, misleading, ... (all too common) understanding proper use of the crypto system may be impossible.
Open source has the virtue that those who can read code well can "reverse engineer" proper operation from the code, thereby avoiding the misleading instructions in the documentation. It also has the virtue that you can compile your own version from the source, reducing the chance of a Trojan Horse in a precompiled binary. It also increases the chance that someone in the public crypto community (who knows what he's about) will notice design or implementation blunders -- no guarantees though.
Checklists for choosing crypto systems are like too much strong drink for some of us. It's a vice I have sworn off, again and again. On the other hand, if you can choose your crypto system to meet each of the 9 points above, you'll increase your chances of avoiding some crypto blunder or other very considerably. No promises that you'll be secure, that the crypto system will be convenient to use, ...
There are no good, easy, answers. There is no solution which simply solves YOUR problem --regardless of any marketing claims. The XYZ package might be optimum for you, but knowing it is hard. It takes careful consideration.
Good luck with it all,
Will"
Bruce Keltz found a good source of info on encryption at www.ssh.com/support/cryptography/
