- cypherpunks-legacy - lists.cpunks.org

Re: Truly Stealthy PGP
by Hal 17 Dec '03

17 Dec '03

From: hughes(a)ah.com (Eric Hughes) > What I suggest is making the exponent (the encrypted session key) > completely random over the length assigned to it, since that's > visible, and just live with a slightly non-flat distribution of > exponents mod n. It turns out that this can be made to work just > fine. > > n is the modulus. Divide L by n to get L = t * n + s, s in [0,n). > Assume x is random in [0,L). The entropy of x mod n is > E = log L/t - s(t+1)/L log( 1 + 1/t ) > > What is the smallest value of E? In other words, what's the upper > bound of the randomness we can lose? It happens when when t = 1 and > when n = L/2+1. This maximize the expression in t and maximizes s at > n-2. This minimum value of E is > > E_min = log L - ( ln 2 - 2/L ln 2 ) > > In other words, the most entropy we can lose is two bits. That's > right, only two bits. Since the entropy of the session key is the > length of the modulus, for a 1000 bit key the entropy loss is > negligible. I'm not sure the point of this entropy calculation. For the case n = L/2+1, t=1, it seems to me that the RSA-encrypted session key (sk^e mod n) is never going to have the high bit set, so with K such messages it should be possible to tell that something is going on with probability 1 - 2^-K. > Therefore, my recommendation is that the session key representation be > chosen randomly over [0,2^k) and to use as an actual session key this > value mod n. The effective entropy loss is small enough not to worry > about. > > Eric > If the session key is chosen from [0,L), still the encrypted session key m = sd^e mod n will be uniform in [0,n). I don't quite follow here how exactly we go from something uniform in [0,n) to something uniform in [0,L), if that is what Eric is proposing. Hal

2 1

Re: some technical steganography
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Eric Hughes wrote: > > >What does "appears relatively random" really mean? How do you > >measure the randomness of a sequence of bits? > > Randomness is the wrong measure. Suppose I take 2^10 > random bits and prepend 16 zeros. How random is this? > Almost as random, and this can be made precise. How > compressible is it? Almost incompressible. Now, what > about 2^20 bit? 2^30? > > It is not randomness but recognizability which is at issue. > One of my assumptions was that the stuff you're trying to hide is not recognizable. In one of my posts I used the phrase "unremarkable encrypted message". I should have said "unrecognizable encrypted message". I assert that an "unrecognizable encrypted message" will be a random sequence of bits. Is my assertion correct? Should I be using the phrase "high entropy" instead of "random"? Assume for the moment that there is a way to produce an unrecognizable encrypted message using public-key encryption. (I leave it to the experts to figure out the best way do that.) I still believe that if the reverse stego process frequently produces high entropy bit sequences, even if there is no hidden message, then the steganography system is successful. If the reverse stego process *always* produces a high entropy bit sequence, then the steganography system is perfect. Of course, this assumes there is no other way to detect a hidden message besides reversing the stego process and testing the result. Obviously, if the forward stego process (inserting the bits) leaves telltale traces, then it doesn't matter what the reverse stego process produces. To summrise, I believe a successful steganography system will include the following steps and have the following properties: step 1) encrypt you plaintext. step 2) hide the encrypted message in a public message (duh) property 1) the result of the encryption step should be a random sequence of bits. property 2) the bit insertion process must not leave telltale traces. property 3) the reverse stego process should product frequent "false hits". In other words, the reverse stego process should frequently produce high entropy bit sequences, even if there is no hidden message. Am I correct? Jim_Miller(a)suite.com

2 1

Re: Update on user-level hack to do telnet encryption posted recently
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

> OK folks, I've started tidying up that hack code I posted recently which > outlined a method for rolling your own telnet-style encryption. I really think this project is a serious mistake. People should, if they insist, produce software compatible with the draft RFCs on telnet encryption and authentication -- although such code has already been written. The notion of putting in all this effort just to avoid having to deal with your system administrator, especially when he should be happy to install such code given the recent rash of internet breakins, seems misplaced to me. Perry, I'm no longer interested in what you have to say. You've been a wet blanket and have pooh-poohed every practical suggestion I've ever seen anyone making - weren't you one of the first people to post to the netphone project telling us we were all wasting our time? Cypherpunks write code, except when asked not to by Perry Metzger. The point of this code, in case you missed it, is so that people can take responsibility for their own encryption and not have to trust software installed by someone else, just like we all use pgp rather than Clipper. Now, if you don't have anything useful to contribute, shut up and stop trying to discourage those who do. G

3 4

Even more unix holy war. Was "Clinton freezes U.S. assets .."
by jamesd＠com.informix.com 17 Dec '03

17 Dec '03

To summarize this thread, and I hope end it. The fans of unix correctly point out that unix can, in principle, be configured to be really nice. Well so can a molten lump of pig iron, in principle, be configured to be something really nice. Out in the real world people do not like dealing with a molten lump of pig iron, and so it is usually not configured to be really nice, which is why we see people editing with vi and publishing with latex. Now sometimes MIS creates a tiny little reserve where things really are really nice, and the secretaries are herded into this little reserve, and within this little reserve everything is almost as nice as windows. (Unless of course you want to cut and paste formatted text and graphics between windows, under the sun OS, but hey, that is an arcane operation that the normal user would never want to do. Right? You cannot really expect MIS to help such special power users can you?) And that is what Bill O'Hanlon meant when he said that for ordinary naive users who had not been exposed to either operating system, unix was no worse than dos. Herd them into the reserve and keep them there, and it is indeed no worse than dos. But the reserve is not really the whole operating system, it is just a little area of safety. And as soon as somebody strolls outside the little reserve to do something that MIS has not specifically planned for and arranged, half a ton of molten pig iron pours down on them, and MIS says: "Hey, don't do that." --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.catalog.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the omnipotent state. | jamesd(a)netcom.com

1 0

Re: Update on user-level hack to do telnet encryption posted recently
by Graham Toal 17 Dec '03

17 Dec '03

As for this current "idea", with an implementation of an encrypted STANDARD telnet already written and likely available soon for anonymous FTP, I think I'm being sane, not "a wet blanket". You can already get a version of the Cray telnet that implements the authentication code and hack in a reimplementation of the encryption code if you wish. See below for that. However, producing silly non-standard telnet hacks makes little sense. Perry, I *already* have the bsd4.4 Kerberized telnet with DES that comes with the BSDI distribution (original code in the US, a re-implementation on supplementary floppies in the UK) - I've had it for half a year now, and you know what? - it's of no use to me at all. Not *one* of the dozen odd sites I telnet to is running it. Maybe in several years time we'll all be running the same encrypted telnet, but for now I want *something* to keep the nosey little kids from reading my packets and if I have to ftp a short source and compile it every time I log in somewhere then that's what I'll do. I bet my telnet sessions are secure a lot sooner than yours are. The degree of that security depends to some extent on how much help I get implementing a stream cypher because I'm not sure I trust myself to do it properly. So I would really appreciate if you don't think this project is worthwhile, that you simply don't contribute rather than going out of your way to encourage others not to as well. G

2 1

Re: Stealth PGP
by Matthew J Ghio 17 Dec '03

17 Dec '03

There are actually several clever ways that you can get around the problem with the RSA encrypted data being less than the modulus. The simplest is to encrypt it more than once. Suppose you have a modulus m of legnth n. You then create a block of data to encrypt, b, of legnth n. If b is less than m, encrypt it with RSA. If not, don't encrypt it. Then take 2^n-b-1 (which, btw, is the same as xoring b with all one-bits). If that result is less than m, encrypt it with RSA. Since m is greater than half of 2^n (it must be, otherwise it would be less than legnth n), all possible plaintexts will be encrypted at least once with RSA, some twice. This does leave a somewhat uneven distribution of values when comparing plaintext and ciphertext (which can be minimized by more encryptions), but that only shows up when and if the message is decrypted; as long as you use random padding properly before encrypting, the encrypted data will look completely random. My ideal "Stealth-PGP" would work something like this: Take a file, encrypt it with a random session key, prepend the session key to the file, encrypt the first n bytes (which include the session key and part of the encrypted data) with RSA if it's less than m, XOR it (reverse all bits), and then encrypt with RSA if that's less than m. Actually, putting the data inside the RSA might not be a good idea, it would not work well for small files unless you added a legnth byte. Maybe the RSA part could just be filled with random padding...

1 0

Re: PGP (surprise, surprise..)
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Joel Mueller asks: > Could anyone tell me, is it true that PGP 2.3 was watered down to > appease the RSA folks? If so, would it be a better idea to use 2.2? > Thanks. No, of course it wasn't. There was some hoax article on the network purporting that PGP was rigged, which didn't even have Phil's name right. First of all, you can look at the code yourself, and see the differences between 2.2 and 2.3 and successors - the discussion on the net centered around bug fixes and getting things to work consistently across platforms. Second (or zeroth), RSA has been annoyed at Phil for a while :-) Among other things that have been done to deal with this, Phil is no longer developing mainstream freeware PGP, though he has worked on licensed commercial versions like ViaCrypt. The PGP official development is going on outside the US, where it's not covered by the PKP/RSA patents and where there isn't a problem exporting the code (US ITAR doesn't forbid importing crypto software.) So don't worry. If you're concerned about not violating RSA's patent, buy the VIaCrypt port for $100 (plus shipping and sales tax.) Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

1 0

Re: New mailing list?
by mcb＠net.bio.net 17 Dec '03

17 Dec '03

I was thinking about Alan's proposal for a moderated real-world-crypto list (which sounds good, by the way!), and it brought up my main problem with cypherpunks, which is sheer volume, volume, volume! It's not a "noise" problem -- since the end of the LD foolishness the greatest part of what has been posted here has been intelligent, thoughtful stuff. But since c'punks has grown to the size of a newsgroup in volume, simply getting through it is *difficult*. My proposal is pretty simple: splitting the list into cypherpunks-tech and cypherpunks-policy. (Cypherpunks-announce would be left alone of course.) I think a large number of readers would want to be on both lists, but a large number (like myself) would *not*, and if nothing else, it would cut down the mailer load on toad. In short, technical crypto articles, reviews of papers, steganography stuff, PGP-specific stuff, all source code, etc., would go to the cypherpunks-tech list; while policy articles, Clipper stuff, political discussions, anarcholibertarian/extropian material, social implications of digital cash, etc., would go to the cypherpunks-policy list. I *know* there are people out there who would rather that the political stuff not get in the way of their technical discussions, and then there are people like me who are more focused on the policy issues (and regardless of technical background, are never going to be code-level crypto hacks). Comments? -- Michael C. Berch mcb(a)net.bio.net / mcb(a)postmodern.com

3 2

Re: Where'd pgptools go?
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

> I notice on csn.org:/mpj there is now pgptl10d.zip, PGP Tools version > 1.0d. However, 1.0d is not the whole PGP Tools program. It is just an > addendum which implements Diffie-Hellman. Apparently pgptl10c.zip is still > needed to give you the whole of PGP Tools. Does anyone know of an FTP > site which still has pgptl10c available? Thanks - > > Hal on wimsey.bc.ca: /pub/crypto/software/dist/US_or_Canada_only_XXXXXXXX/RSA/PGP/PGPTOOLS: total 328 -rw------- 1 markh user 0 Feb 23 11:11 DO_NOT_EXPORT -r--r--r-- 1 markh user 21076 Feb 23 11:10 mgmny10e.zip -r--r--r-- 1 markh user 143871 Feb 23 11:10 pgptl10c.zip cd into /pub/crypto/software and read the README file for the current value of XXXXXXXX -- Mark Henderson markh(a)wimsey.bc.ca (personal account) RIPEM MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433 ViaCrypt PGP Key Fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 cryptography archive maintainer -- anon ftp -- wimsey.bc.ca:/pub/crypto

1 0

A useful quote/stat to spread
by Stanton McCandlish 17 Dec '03

17 Dec '03

"In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", _TIME_, Mar. 4 1994

1 0