Re: The War is Underway (fwd)
On Sat, 10 May 1997, Adam Back wrote:
Tim May <tcmay@got.net> writes:
However, while we may think their power is gone, or is almost gone, they think otherwise. And we're seeing an accelerating pace of lawmaking, [...]
[The fork in the road is discussed]
Who will actually win?
I think we will. They think they will. The war is underway.
So what are we doing to fight our side? (Apart from fantasizing about nuking the bastards till they glow :-)
So what can cypherpunks do?
Write code?
Yes. One of the major stumbling blocks I have run into is a lack of code which really is refined and reviewed enough to serve the purposes I need it to serve. FC97 did a lot to make some more obscure things obvious, and familiarize the players with each other, but the details are often hard to come by. Many of the applications out there are painfully behind in interface areas forcing developers to use complicated "toolkits" which often lack the basics we need. Finding an analogy to easily explain even the basics to a customer is very difficult unless the front end jibes with the attempt. The amount of confusion over what represents a good algorithm is also interesting. Take CAST, which seems a promising cipher and which we considered using over IDEA. On asking 4 "experts" about CAST, I got 4 answers. 1> A 64 bit cipher with 40 bits secret. 2> A 64 bit cipher - not expected to be very complete. 3> A 128 bit cipher. 4> "Not worth discussing." In fact, as I understand it, CAST is of variable key length (Up to 128 bits), and quite resistant to many attacks which plague DES and even IDEA. But digging out that information was painfully difficult. (It may not even be correct).
Perhaps it's time for some stego interfaces to remailers.
Usually around this time Black Unicorn gives us his wish list of crypto anarchy apps. I'm not sure we've progressed much towards his wish list since the last time he posted it.
Most of what concerns me is the need to keep keylengths "obscenely large" because what is obscene today may not be so obscene after 5 years of chilled crypto development. Given the success (or lack thereof) of my call to arms before, I'm not sure I'll be anxious to repeat it soon. (The largest keylength of any widely used cipher of which I am aware remains at 128. There still is no effective PipeNet, no real mainstream "stealth crypto." No significant work on detering traffic analysis or denial of service with the exception of the below).
I thought the Eternity Service I announced a week or so ago was a step towards reducing the possibility for government censorship of web pages. (http://www.dcs.ex.ac.uk/~aba/eternity/) Not much interest to date. Ideas stand on their merit, but the success of crypto anarchy services also depends on ease of use, funding, volunteer effort, publicity, and evangelizing. I haven't done much of the latter yet lacking an example server to bootstrap the system, I hope to have this up in a few weeks.
Hearty kudos. An online bank is useless if it can be blocked by a few keystrokes. (But that's what secure INMARSAT phones are for too) Still, these are areas that I wish c'punks would start looking at again. Even if strong unforfeited crypto is legal in the U.S., it will not be in other countries for quite some time. There is strength in numbers, not just safety. The more crypto users there are, the less government, or anyone else, can do about it. C'punks should wish to provide clandestine crypto services for the entire population. Laws which may or may not pass in the United States should bore c'punks, because they should realize that legislation is irrelevent because the genie is already out of the bottle. Unfortunately, I don't think the genie is all the way out of the bottle. NOTE: I'm not on cypherpunks anymore, mail me directly for replies. -- Forward complaints to : European Association of Envelope Manufactures Finger for Public Key Gutenbergstrasse 21;Postfach;CH-3001;Bern Vote Monarchist Switzerland Rebel Directive #7:Avoid soccer games when a government assault threatens.
On Sat, May 10, 1997 at 06:17:56PM -0400, Black Unicorn wrote:
On Sat, 10 May 1997, Adam Back wrote:
Tim May <tcmay@got.net> writes:
However, while we may think their power is gone, or is almost gone, they think otherwise. And we're seeing an accelerating pace of lawmaking, [...]
[The fork in the road is discussed]
Who will actually win?
I think we will. They think they will. The war is underway.
So what are we doing to fight our side? (Apart from fantasizing about nuking the bastards till they glow :-)
So what can cypherpunks do?
Write code?
Yes. One of the major stumbling blocks I have run into is a lack of code which really is refined and reviewed enough to serve the purposes I need it to serve. FC97 did a lot to make some more obscure things obvious, and familiarize the players with each other, but the details are often hard to come by. Many of the applications out there are painfully behind in interface areas forcing developers to use complicated "toolkits" which often lack the basics we need. Finding an analogy to easily explain even the basics to a customer is very difficult unless the front end jibes with the attempt.
The amount of confusion over what represents a good algorithm is also interesting. Take CAST, which seems a promising cipher and which we considered using over IDEA.
On asking 4 "experts" about CAST, I got 4 answers.
1> A 64 bit cipher with 40 bits secret. 2> A 64 bit cipher - not expected to be very complete. 3> A 128 bit cipher. 4> "Not worth discussing."
In fact, as I understand it, CAST is of variable key length (Up to 128 bits), and quite resistant to many attacks which plague DES and even IDEA.
But digging out that information was painfully difficult. (It may not even be correct).
http://adonis.ee.queensu.ca:8000/cast/cast.html Also http://www.entrust.com/library.htm [Caveat: I am not a cryptographer.] [...]
Still, these are areas that I wish c'punks would start looking at again.
Unfortunately, c'punks seems bogged down in macho fantasies about guns.
Even if strong unforfeited crypto is legal in the U.S., it will not be in other countries for quite some time.
There is strength in numbers, not just safety. The more crypto users there are, the less government, or anyone else, can do about it.
Hence the value of the "Crypto is Cool" approach. A valuable addition would be crypto packages designed for high school kids. All my many nieces and nephews are on the net... -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
-----BEGIN PGP SIGNED MESSAGE----- On Sat, 10 May 1997, Black Unicorn wrote:
The amount of confusion over what represents a good algorithm is also interesting. Take CAST, which seems a promising cipher and which we considered using over IDEA.
On asking 4 "experts" about CAST, I got 4 answers.
1> A 64 bit cipher with 40 bits secret. 2> A 64 bit cipher - not expected to be very complete. 3> A 128 bit cipher. 4> "Not worth discussing."
In fact, as I understand it, CAST is of variable key length (Up to 128 bits), and quite resistant to many attacks which plague DES and even IDEA.
But digging out that information was painfully difficult. (It may not even be correct).
According to _Applied Cryptography_, CAST is a Feistel cipher with a 64-bit block length and 64-bit key length. So far, brute force is the only known attack. As far as "obscenely large" key lengths are concerned, 3-key triple DES uses a 168-bit key. This is used in many crypto packages, including export-controlled Netscape, and is being considered as a replacement for DES in the U.S. Triple DES will probably also be supported in the next version of PGP. Blowfish supports keys as long as 448 bits and RC4 supports keys up to 2048 bits. The problem with variable length ciphers is that programs that use them to not actually take advantage of variable keys and just stick to using keys of a fixed, and small, size. Using large key sizes for passphrase-based systems is difficult, because it's just too difficult to remember a passphrase with enough entropy to make a difference. Assuming a random passphrase with 6 bits of entropy per character, over 21 characters would have to be used for there to be 128 bits of entropy. Systems that use randomly generated keys are limited only by the amount of available entropy, but then the passphrase security to encrypt the secret key or physical security become important. Using excessively long keys does not do much for security, as there are always going to be weaker links that an attacker can take advantage of. It doesn't hurt to use a 256-bit key, or larger, but it doesn't do much good, either. Mark -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQEVAwUBM3UK/yzIPc7jvyFpAQEhIwf+NYr0gHWWd2r056+MCZp/v5Y5KmpdxSz8 mXOM+GOm4bxk5OufCcw7FWKoJYNxklII3yDl1s9+xd5iegwX7T+rRWo1qc1/MAOJ JJdMxy87T6qHgO28GUa6eNe/3g9d76z4U3E95u4mNMVs4mEQcD16lgXpfZPDZO0z c7SxEfAK2rCxZeakZ0c/QEgraWIYLjpyl0EsHNVw+PszlGtrQKEFSJNSGI9dhKkc WT6oHiisE1F+GNLn7PyBzby8HxEW9zwWSU3coa75yqwHfNNVCkb/s2Yh3cyw5LhP mrMlQcVBH6A4J5iJQJcEfoKN9p+rZA/Rl5FjApWFG3cVMxq0ZXGjZg== =eI9X -----END PGP SIGNATURE-----
On Sat, 10 May 1997, Mark M. wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On Sat, 10 May 1997, Black Unicorn wrote:
The amount of confusion over what represents a good algorithm is also interesting. Take CAST, which seems a promising cipher and which we considered using over IDEA.
On asking 4 "experts" about CAST, I got 4 answers.
1> A 64 bit cipher with 40 bits secret. 2> A 64 bit cipher - not expected to be very complete. 3> A 128 bit cipher. 4> "Not worth discussing."
In fact, as I understand it, CAST is of variable key length (Up to 128 bits), and quite resistant to many attacks which plague DES and even IDEA.
But digging out that information was painfully difficult. (It may not even be correct).
According to _Applied Cryptography_, CAST is a Feistel cipher with a 64-bit block length and 64-bit key length. So far, brute force is the only known attack.
As far as "obscenely large" key lengths are concerned, 3-key triple DES uses a 168-bit key.
As I recall, 3des ( DESk1 -> DESk2^-1 -> DESk3 ) has an effective keylength of 112 bits. Less than IDEA. Schneier discusses this.
Using large key sizes for passphrase-based systems is difficult, because it's just too difficult to remember a passphrase with enough entropy to make a difference. Assuming a random passphrase with 6 bits of entropy per character, over 21 characters would have to be used for there to be 128 bits of entropy.
I dislike this line of argument for several reasons. It reduces security to the lowest common denominator. Because, the argument goes, few people will use more than a 21 character passphrase, then we need not design anything with more security. In reality, I think that the percentage of people who use more than an 8 character passphrase, especially outside these circles, is small. Following your logic, our high end of security should be about 48 bits.
Systems that use randomly generated keys are limited only by the amount of available entropy, but then the passphrase security to encrypt the secret key or physical security become important. Using excessively long keys does not do much for security, as there are always going to be weaker links that an attacker can take advantage of. It doesn't hurt to use a 256-bit key, or larger, but it doesn't do much good, either.
Again, you have taken an important concept, total security, and reversed it. Instead of aiming to make each link as strong as possible, you have aimed to design around the weakest link. This is a serious mistake in my view. It costs little today to develop a cipher with larger keyspace. (DES with independent subkeys already exists and has a basic keyspace of 768 bits. A meet in the middle attack reduces keyspace to 2^384. Schneier discusses the cipher briefly). If users are willing to deal with large keys (I certainly am) then software designers are restraining a more secure implementation. I think most will agree that anything over 150 bits makes brute force a losing effort. Unfortunately it has to be deployed first.
Mark -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv
iQEVAwUBM3UK/yzIPc7jvyFpAQEhIwf+NYr0gHWWd2r056+MCZp/v5Y5KmpdxSz8 mXOM+GOm4bxk5OufCcw7FWKoJYNxklII3yDl1s9+xd5iegwX7T+rRWo1qc1/MAOJ JJdMxy87T6qHgO28GUa6eNe/3g9d76z4U3E95u4mNMVs4mEQcD16lgXpfZPDZO0z c7SxEfAK2rCxZeakZ0c/QEgraWIYLjpyl0EsHNVw+PszlGtrQKEFSJNSGI9dhKkc WT6oHiisE1F+GNLn7PyBzby8HxEW9zwWSU3coa75yqwHfNNVCkb/s2Yh3cyw5LhP mrMlQcVBH6A4J5iJQJcEfoKN9p+rZA/Rl5FjApWFG3cVMxq0ZXGjZg== =eI9X -----END PGP SIGNATURE-----
-- Forward complaints to : European Association of Envelope Manufactures Finger for Public Key Gutenbergstrasse 21;Postfach;CH-3001;Bern Vote Monarchist Switzerland Rebel Directive #7:Avoid soccer games when a government assault threatens.
Black Unicorn wrote: | > Systems that use randomly generated keys are | > limited only by the amount of available entropy, but then the passphrase | > security to encrypt the secret key or physical security become important. | > Using excessively long keys does not do much for security, as there are | > always going to be weaker links that an attacker can take advantage of. | > It doesn't hurt to use a 256-bit key, or larger, but it doesn't do much | > good, either. | | Again, you have taken an important concept, total security, and reversed | it. Instead of aiming to make each link as strong as possible, you have | aimed to design around the weakest link. | | This is a serious mistake in my view. I disagree with your approach. In the real world, budgets are limited, time is limited, the pool of really decent people on any given project is small. Fixing or strengthening the weakest link is my usual approach to these things. Not as nice as having a bulletproof design from the start, but there aren't enough smart cypherpunks out there consulting. (More on that in another post.) | It costs little today to develop a cipher with larger keyspace. (DES with | independent subkeys already exists and has a basic keyspace of 768 bits. | A meet in the middle attack reduces keyspace to 2^384. Schneier discusses | the cipher briefly). If users are willing to deal with large keys (I | certainly am) then software designers are restraining a more secure | implementation. It takes an academic cryptographer about 6 months to develop a cipher. Most academics don't see a point to moving beyond the 448 bits available in Blowfish. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
On Tue, 13 May 1997, Adam Shostack wrote:
Black Unicorn wrote:
| > Systems that use randomly generated keys are | > limited only by the amount of available entropy, but then the passphrase | > security to encrypt the secret key or physical security become important. | > Using excessively long keys does not do much for security, as there are | > always going to be weaker links that an attacker can take advantage of. | > It doesn't hurt to use a 256-bit key, or larger, but it doesn't do much | > good, either. | | Again, you have taken an important concept, total security, and reversed | it. Instead of aiming to make each link as strong as possible, you have | aimed to design around the weakest link. | | This is a serious mistake in my view.
I disagree with your approach. In the real world, budgets are limited, time is limited, the pool of really decent people on any given project is small. Fixing or strengthening the weakest link is my usual approach to these things. Not as nice as having a bulletproof design from the start, but there aren't enough smart cypherpunks out there consulting. (More on that in another post.)
I conceed this general point, but in context it does not stand up. Specifically we were referring to the trade off between cipher keylength and password size. It was proposed that because people were unlikely to deal with passwords large enough to fill the key with e.g., 128 bits of entropy, that it was worthless to bother with 128 bit symetric ciphers. I find this a hard position to support.
| It costs little today to develop a cipher with larger keyspace. (DES with | independent subkeys already exists and has a basic keyspace of 768 bits. | A meet in the middle attack reduces keyspace to 2^384. Schneier discusses | the cipher briefly). If users are willing to deal with large keys (I | certainly am) then software designers are restraining a more secure | implementation.
It takes an academic cryptographer about 6 months to develop a cipher. Most academics don't see a point to moving beyond the 448 bits available in Blowfish.
Ok, where are the 256+ bit blowfish implementations?
Adam
-- "It is seldom that liberty of any kind is lost all at once." -Hume
-- Forward complaints to : European Association of Envelope Manufactures Finger for Public Key Gutenbergstrasse 21;Postfach;CH-3001;Bern Vote Monarchist Switzerland Rebel Directive #7:Avoid soccer games when a government assault threatens.
-----BEGIN PGP SIGNED MESSAGE----- On Sun, 11 May 1997, Black Unicorn wrote:
As I recall, 3des ( DESk1 -> DESk2^-1 -> DESk3 ) has an effective keylength of 112 bits. Less than IDEA. Schneier discusses this.
That's only the best case (for the cryptanalyst). Breaking 3DES with only 2^112 encryptions requires 2^56 plaintext-ciphertext pairs. Schneier says this is about 10^17 bytes.
I dislike this line of argument for several reasons. It reduces security to the lowest common denominator. Because, the argument goes, few people will use more than a 21 character passphrase, then we need not design anything with more security.
In reality, I think that the percentage of people who use more than an 8 character passphrase, especially outside these circles, is small. Following your logic, our high end of security should be about 48 bits.
Very true. I was not arguing that security should be reduces to the lowest common denominator but that using excessively long key sizes does little good. Anything over 256 bits is, IMHO, overkill and 160 bits is enough to make brute-force attacks infeasible.
It costs little today to develop a cipher with larger keyspace. (DES with independent subkeys already exists and has a basic keyspace of 768 bits. A meet in the middle attack reduces keyspace to 2^384. Schneier discusses the cipher briefly). If users are willing to deal with large keys (I certainly am) then software designers are restraining a more secure implementation.
I'm very suspicious of any cipher with independant subkeys. Apparently, this makes chosen-key attacks *very* easy. Chosen-key attacks aren't very practical, but it doesn't give me a good feeling about the relative security of the cipher. Some combination, like triple-DES using variable S-boxes would probably be a little more secure. Mark -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQEVAwUBM3ekFyzIPc7jvyFpAQE21Qf/bepXHyyXBPY33tytKtWQh3isjzqrSqH2 nOtg8qbuDI31W9Jo3RK2KN4nvHLHyPjlrkTT4M07oOhBqNm/Y+xD7ABOvnxkzVal L7jQbqF3iaJZRhHUyMP0tI+RlyIdtHTN0l7Qt+P/Jfb81uBm5sGPMh9vM3s9/Wav oP/XHvkX24OnDlnIfpMj+WnLyXx1a6Rs9oyEfv+/k1/7Lo9UwZMSdjV36UDNj8kG gYBA7eCLMs+3OfcKAlP4wD8TgBfzD3DH93ME5eBtAM/yYzQI5X+tdpIZJ2C3wFZI oX89+1Kh1AgHJ3Hj7mZKJGvlT3S3rSxL36CQUDAH9NNAPpazOPC3Vg== =Kwd2 -----END PGP SIGNATURE-----
participants (4)
-
Adam Shostack -
Black Unicorn -
Kent Crispin -
Mark M.