- cypherpunks-legacy - lists.cpunks.org

No Subject
by pohl＠unixg.ubc.ca 17 Dec '03

17 Dec '03

subscribe ----- Derrick Pohl <pohl(a)unixg.ubc.ca>, Faculty of Graduate Studies University of British Columbia, Vancouver, B.C. Ph. (604) 822-9546 Fax (604) 822-5802

1 0

Re: REAL WORLD ENCRYPTION
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 21:36 2/17/94 -0500, Sandy wrote: >What is a "debit" card? It is just like a credit card, except >that it is used to debit your bank account immediately rather >than extend you credit--at interest--for later repayment. They >are issued by Mastercard, Visa and other card companies. They >look, and are used, just like a regular credit card. They are >anonymous because there use creates no audit trail pointing to >you. Further, the bank will keep its records in a jurisdiction >that protects the privacy of such business records. For the >truly paranoid, the bank will issue corporate debit cards. Perhaps you can sell your technology to government witness protection programs. Perhaps you could even sell your service if you could prove that only the money was at risk (and not the location of users).

2 1

Re: Mac encryption
by dmandl＠lehman.com 17 Dec '03

17 Dec '03

> From: Ron Davis <rondavis(a)datawatch.com> > > > dmandl(a)panix.com said: > > > >Cypherpunks do have an interest in all forms of crypto, but there are > >very good reasons why public key is more desirable than symmetric for "our > >purposes." This is at the very root of the crypto revolution and the > >cypherpunk ethos. Have you done the basic reading? (That's a serious > >question, not sarcasm.) > > Depends on what the required reading list for this group is. > I thought that our purposes were to promote the privacy of > individuals through the use of cryptography. This can be done > in the contexts I talked about with symmetric as well as PK crypto. The invention (discovery?) of public-key crypto changed the world, and makes practical everyday use of crypto infinitely easier. It also makes the kinds of specific things cypherpunks are interested in much more practical (or POSSIBLE). If you correspond with hundreds of people on a regular basis, including people you don't know and people you may send something to once and never deal with again, it is impractical to say the least to have to generate and exchange keys. That's the basic argument. Why was public key crypto invented at all? Why are people interested in using it? Practically, it's really fundamentally different from symmetric crypto, which is of very limited use in the situation we're all in now (anonymous communication, the net, quick hit-and-run dissemination of information, digital signatures, etc., etc.). PGP also has the "web of trust" structure built in. This is worlds away from basic symmetric crypto. This is really basic stuff, so I'm hesitant to discuss it on the list. > Maybe I have the wrong idea about "our purposes", please correct me > if I'm wrong. If you're relatively new to the list, try to get your hands on some of the basic cypherpunk material, like tcmay's Crypto-Anarchy manifesto, the cypherpunk articles in Wired or Whole Earth Review, etc. There are many different views represented on the list, but I think we all agree on the significance and importance of pk crypto. Symmetric is fine for hiding things from your boss. PK is intended for different purposes. > >And of course, it does all the public-key encryption and key-management as > >well. A pretty incredible package, considering its size and cost. > > You're right its free. If something is free you can't really complain > about it. If it does anything its a bargan. I didn't mean to insult PGP by claiming that it's worth the price ($0). It's actually worth much more. I was just saying that for free it's an astounding deal. --Dave.

1 0

Crypto conference in Santa Barbara
by solovay＠math.berkeley.edu 17 Dec '03

17 Dec '03

What follows is the call for papers, in latex. For the latex-impaired, the conference will be in Santa Barbara on August 21--25, 1994.

1 0

Hacktic remailer works?
by Mike Ingle 17 Dec '03

17 Dec '03

Does the remailer at hacktic work? I've tried it and have not received a response. Does it use the standard syntax? --- Mike

1 0

your guess
by hkhenson＠cup.portal.com 17 Dec '03

17 Dec '03

dThe other day I was asking myself out loud just what the heck is going on with Bill and Al and their oddly strong support for Clipper. A voice said ask not *that* question, but who is it that has a *lot* of influence over them, and what three letter agency were they working for a while back? Hmm. Could this describe a certain person who decided against being Sec. of Defense? Very good! said the voice. Now, what kind of reason could people in the highest positions in the US have for doing things which are rather impolitic and out of character for them? Well, I said, *I* don't know what kind of pressure might be brought to bare, but "no such agency" *would*. Do you think they would have the nerve to blackmail a prez? The voice softly said "Kennedy and Hoover."

1 0

Mac securedrv help..
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Hey guys I posted this message all over AOL, CIS, Fido and UseNet. I'd like to post it on here as well. If you happen to know someone who has written disk drive device drivers for the mac, please forward this to them so that I can write something like SecureDrive for the Mac. :-) (I've already written some vastly cool, vastly portable code thatprovides much much more than an encrypted drive!) I will make a FREE no-frills crypto-drive available (only in the USA of course...) but there will also be something along the lines of a shareware crypto-stacker with data compression and encryption. I've written most of the compressor related code already, and tried to keep it fairly portable... This should give eDisk, Stacker, and x2 a bit of healthy competition. :-) (It will be VERY low cost compared to them.) Hey there, I tried to get a printed copy of InsideMac:Devices, however it won't be published for a while. In the mean time, I printed out some of the relevent chapters from the beta version on the d e v e l o p bookmark cd... I'm trying to write a disk device driver that will be loaded from an application (after the Mac is started up, and INITs have loaded.) I already have code that installs a driver in this manner. I've looked at the SCSI C/ASM sample code on the CD... But, here are some questions I still have: Is it okay for my driver to call FSRead FSWrite from its Prime routine? (It will be reading from a file or writing to a file.) Do I have to make the driver asynchronous? If not, how do I tell the OS that it isn't async? If yes (or if asynch is better) how do I write such a beast? The demo SCSI driver is synchronous, however I hear that the new AV macs use asynch drivers. Would an async driver work on older Macs? Would a non-async driver work on an AV Mac? Where can I get sample code for an Async disk driver? All I need is basically a bit of a source code skeleton that I can stick in READ_A_BLOCK, WRITE_A_BLOCK, Initialize, and Shutdown functions... Also, a MAJOR thing, how do I set the sector/block size of a disk device driver such as the one I'm writing? I understand that 512 bytes seems to be the size in general. I also understand that the Mac clusters sectors together if the drive is larger than 65535 sectors because of the pointers it uses. (I'd like to be able to use 512, 1024, 4096, or even upto 32K sectors in my driver, but if 512 is the normal it's not too big a deal...) I have written most of the routines that this driver needs, but I need a working, good skeleton of a driver, and as the warnings on the SCSI sample code indicate, I don't trust it. :-) Thanks. (if you'd like to email me the replies instead, my internet address is: rarachel(a)photon.poly.edu. This is preferred since I generally get to the photon machine more often...) ---------On countless worlds the earth shakes as the forces of Chaos strive to gain control. Whilst they unleash their devastating weaponry upon their foes there is no time for peace - only Eternal War.

1 0

;pgpit
by Hal 17 Dec '03

17 Dec '03

I was just logging out, by typing "logout". I accidentally placed my right hand on the wrong keys, offset to the right by one. Instead of "logout", what appeared on my screen was ";pgpit". Good idea! One we should all take to heart. ;-) Hal

1 0

RE: MONEY: cryptocash is transaction money
by Pat Farrell 17 Dec '03

17 Dec '03

In message Thu, 17 Feb 94 12:41:00 -0800, hughes(a)ah.com (Eric Hughes) writes: > I've been getting questions about digital money lately which indicate > a basic misunderstanding of its most important feature. Crypto cash > is a way of moving money, not a way of holding money. > > Crypto cash is like a check or a note rather than like the dollar, > franc, or mark. Crypto cash is a way of increasing one person's > balance and decreasing someone else's balance. > > Since it's not a currency, it's not sensible to talk about its > exchange rates. Digital money can be denominated in any currency you > like, so long as you have a bank or other financial institution to > handle it for you. > > This is only an obvious distinction if you already know it. "Money" > is such an overloaded word that it's easy to get confused. > > If this isn't clear, _please_ let me clarify. If you don't get this, > none of the rest of the digital money discourse will be > understandable. I've been following the digital money issues here for quite some time, and I do not understand this distinction at all. Sandy said essentially the same thing in different words, and that too was beyond me. Except for tangible money (i.e. 99.99% pure gold coins) I don't see that any money is anything other than a mutially agreed upon way of moving "barter tokens" between folks. Sometime the government (or Fed) can define the true value of the barter tokens, and othertimes their attempts fail. When the attempt fail, the usual course is to have a "devaluation" that reflects market realities. I don't see how digital money is fundamentally different than private bank notes that were common in the US in the last century. They are good if they are accepted, and useless if not. If this is really a critical distinction, since I don't see it, I'd appreciate a more concrete explaination. Thanks Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

2 1

Stealth PGP and Stegonagraphy (LONG)
by Sergey Goldgaber 17 Dec '03

17 Dec '03

Making Stealth PGP (random noise) Files "Undetectable" INITIAL PROBLEM: The following ideas were developed in response to the concern over the future legal implications of possessing encrypted files. If non-Clipper encryption becomes illegal, even the mere possession of possible non-Clipper-encrypted files may be grounds for a search warrant, confiscation of equipment, and miscellaneous court sanctions. PRACTICAL OBJECTIVE: The possession of encrypted files must be made virtually undetectable, even to the most determined and best informed opponent. BASIC PREMISE: On many machines the file system allows users to "delete" files without actually erasing them. This is usually accomplished by simply marking the disk blocks that make up the file as free. Thus it is possible to write an encrypted (noise) file on to disk, pad the rest of the disk with more noise and "delete" the whole thing, making the disk look blank to all casual observers. CHALLENGES: I - Miscellaneous disk writes, such as those performed routinely by DOS, can overwrite the "deleted" files. II - Certain security measures on the part of the user may make recovery of the hidden file non-trivial. Ideally, the file will not have an "End Of File" marker, a file name, nor an entry in the File Allocation Table. III - Upon examination of the deleted segment of a disk, the aware opponent will notice the discrepancy between a large, highly-random noise-segment and the "structured garbage" that will make up most of the rest of the deleted portion of the disk. PROPOSED SOLUTIONS: I - To ensure the integrity of the hidden data, all disk writes must be directly controlled by the user, not DOS. A - Use of a floppy disk is recommended; as, controlling each individual disk-write operation on a harddrive becomes infeasible due to the large amount of said operations. B - The user should specify and keep track of the exact address and length of the encrypted file when writing it to disk. The file's location/length should be guarded as dearly as one's secret key and corresponding password, for similar reasons. II - Keeping track of the exact address and length of the hidden file will allow easy file recovery, without need for an EOF marker, a file name, nor a FAT entry. III - In order to make one's file deleted file virtually indistinguishable from the rest of the deleted portion of the disk, the implementation of one of the following measures is recommended. A - Split the noise file into small individual files and scatter them throughout the "structured garbage" that is already on the disk. It should blend in with the other little pieces of highly random noise that are naturally interspersed in the deleted portion of the disk. Recovery would, of course, require one to keep track of the addresses, lengths, and order of the component files. B - Use a stegonagraphy utility to hide one's file in a segment of "structured garbage". A Mimic function with a "structured garbage" grammar would be highly usefull for this. DISCUSSION: All of the above speculation relies on the use of Stealth PGP, or a similar program that encrypts plaintext into a format indistinguishable from random noise. Unless this stegonagraphic function is implemented detection of the encrypted file, even when hidden among megabytes of other "deleted" files, will be trivial; as, PGP has a distinct header. The success of the above method also relies on the use of non-standard locations for the hidden files. For, if this method becomes popular, _and_ everyone starts hiding their files in the last few sectors of the disk, for example, a significant portion of the method's effectiveness may be compromised. It should be noted that as long as the user is writing directly to and reading directly from the disk (bypassing DOS), "deletion" of the file is no longer necessary. It is necessary to keep the blocks one writes to marked as "FREE", "BAD" or "DELETED" (take your pick!). Some modification of the FAT or equivalent may be required here. SUMMARY: In order to hide a Stealth PGP (or equivalent) encrypted "noise" file effectively one may follow the steps outlined below: 1 Embed it in "structured garbage" such as is present normally on the deleted portions of the disk. This can be accomplished by using a stegonagraphy program or by splitting the file into small segments and scattering them among "structured garbage". 2 Write the resulting "structured garbage"/noise combination directly to disk. This can be accomplished by using a normal disk-sector editor utility. 3 Keep track of the exact location and size of the file if you want to retrieve it later. Keep this information secure. 4 Modify the FAT (or equivalent) to mark the sectors you've written to as "FREE", "BAD", or "DELETED" (if necessary). In order to retrieve and reconstruct one's file simply reverse steps 2 and 1. THANKS: I wish I could thanks everyone who has commented on this thread individually. Unfortunately, I am rather new to this. Next time, I'll know to keep track of each response/address/name instead of simply replying to your mail/posts. You know who you are. Thank you! Keep you comments flowing! All feedback welcome, Sergey

1 0