Black Unicorn <unicorn@schloss.li> writes:
[avoiding government is the only way]
2: Avoid the Government
I am convinced this is the only answer. It has essentially always been the cypherpunk answer. "Cypherpunks write code." Cypherpunks get it done. etc. Get the genie out of the bottle and keep it there. This is PGP, this is ssh, this is SSL, this is mixmaster, this is remailers. Get it out, get it working, get there first.
Ok. We got some of it there. Now what? The lead time on crypto is about up. In my estimate regulation will be in place by 1998, if not earlier. Remember that in many countries regulation already exists.
Efforts put on resisting or moderating crypto are fine. Political action is fine. Even so I submit that technological action is more important at this stage. The delaying games are about over.
Where is highly sophisticated stego?
Good stego is difficult. Very low bandwidth stego is doable, but stego of reasonable bandwidth, and good plausible deniablity is difficult. What are our options? - Stego in english text. Highly desirable, but very difficult, I think. - Stego in audio and graphic file formats Easier. Not so much plausible deniability. You've got to scan your own pictures, and post lots of them. (Become an avid alt.binaries.pictures.* poster?) - Stego in Internet Phone protocols. Bill Stewart discussed some of the problems with this a short while ago. If I recall the basic problem is that the higher quality lossy audio compression CODECs, which typically get used for low bandwidth (28.8k and below modems) to get reasonable quality, don't have that much room left, as they are compressing, and lossy, and by design trying to leave as little as possible redundancy left. I have also seen claims made for digital watermarking, that if enough channels and redundancy is used, that digital watermarking survives all kinds of abuse, analogue reproduction and redigitizing, etc. Digital watermarking that I have seen discussed most involves image files. Is there any published work on digital watermarking of audio files? It would be interesting to see if any audio watermarking techniques survives internet phone CODECs. However, the problem still is that the two aims are in tension: stego is trying to make the fact that the data is there at all undetectable, the main aim with watermarking is that you not be able to remove all traces of watermarking, and the way that this is achieved is to spread the watermarking through many channels. The fact that there is watermarking in the document is not necessarily being concealed, the primary aim is to stop removal, and encode the watermark so that the image is not appreciably damaged visually. - Stego in Internet video conference formats This kind of technology is difficult for similar reasons to that of audio. Also the technology is a bit premature, I don't think you would be able to get a very good frame rate of high resolution video over a 28.8k modem.
Where are larger keys for symetric ciphers?
The recent discussion on using IDEA with larger keys, or using 3IDEA (triple IDEA) might be one way to get larger key spaces. Peter Gutmann's MDC or the Luby-Rackoff method for constructing a CBC mode block cipher from hash functions are another way. However, Schneier, in AC2 voices concerns about basing ciphers on hashes because the design goals for hashes are different from those for symmetric ciphers. I would be interested to discuss the options of combining cryptosystems so that the resulting cipher is as strong as the strongest of the used ciphers. For instance ways to combine IDEA, 3DES, and MDC say, such that all 3 have to be thoroughly broken before the combination is broken. How good is simple multiple encryption: C = IDEA( key1, 3DES( key2, MDC( key3, M ) ) ) The same question for public key, how good is: C = RSA( pk1, ElGamal( pk2, Rabin( pk3, M ) ) ) mixing in a PK system based on a hard problem other than one based on discrete logs / factoring would be nice also, in case there turn out to be problems in this area. Also Schneier has this one: generate a one-time pad P, XOR it with the data M, then: C = IDEA( P ) || 3DES( P XOR M ) generating the pad is left as an exercise to the reader (just remember, you need at least 112 + 128 bits of security). Also this has the problem that it doubles the message size, but it is guaranteed to be as hard to break as breaking both IDEA and 3DES (or whatever algorithms it is you are using). Also another problem for all of this, you need really top quality random number generators, to get full use from your long key length algorithms.
Where is a fully functional and secure "stealth PGP"?
PGP stealth 2.01 beta is at: http://www.dcs.ex.ac.uk/~aba/stealth/ It is not release quality. I've been meaning to fix that for a while now, a release version will be out RSN. Do you, or anyone else who is interested see any advantage in having stealth functionality integrated into PGP, say as a patch for PGP263i / mit PGP262? Not that hard to do, if there's any interest for it to be integrated. Zbigniew Fiedorowicz <fiedorow@math.mps.ohio-state.edu> added stealth and SHA1 support directly to a MAC version of PGP. The key words `fat mac pgp' in a www search engine would probably find it. Or `Zbigniew pgp'?
Where are anonymous and encrypted WWW clients and hosts which permit chaining?
Folks working on this? Adam -- print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`