- cypherpunks-legacy - lists.cpunks.org

Re: Tempest@home?
by karn＠qualcomm.com 07 Jun '93

07 Jun '93

A good source of general info on RFI (radio frequency interference) suppression can be found in amateur radio publications. THe same techniques hams use to keep their computers from interfering with their radios can be used to keep your computers from getting into the NSA's receivers... Phil

1 0

ROT-13 hoopla on EchoMac
by A1 ray arachelian 07 Jun '93

07 Jun '93

I seriously hope that this won't be way too off topic for this group, but I seem to have painted myself into a bit of a corner recently on FidoNet. Basically, it all started when someone requested a copy of a ROT-13 extension to a popular Macintosh programmer's editor called BBEdit. Soon after, the discussion was joined by the fatheaded sysops who would bible thump on the FidoNet rules that ROT-13 was encryption and as such it is outlawed on FidoNet. To make a long story shorter, in my plight to enlighten these folks (and the moderator of EchoMac who saw fit to banish me for posting a message encrypted with ROT-13,) I got a bit out of hand and started the usual on the soap-box preeching which included a message inviting everyone to join in the conversation by getting the ROT-13 extension. The rest of that message was "encrypted" by ROT-13. Now since ROT-13 is merely nothing more than A=N, B=M, C=O, D=P... and is fairly standard, I've got it on my head to convince the moderator that ROT-13 is not actually an encryption method. The FidoNet policies state that Fidonet cannot provide any sort of privacy as a measure to protect sysops from taking the heat for the possible illegal activities of users. Clearly, ROT-13 does not provide the least bit of privacy, save from a total computer neophyte. So, the reason I'm writing this here was basically "to go to the experts of encryption," and try to get them to agree with me that ROT-13 has never been a form of encryption because its purpose does not provide privacy. So I'm just asking you to agree with me, and I'll send the results to the moderator in question. If you'd like, mail me the responses directly so we won't clutter cypherpunks further, and I'll forward them myself. If you'd like, the moderator's address on FidoNet is Steve Ebener@1:152/42,FidoNet (this should be reachable via Steve.Ebner(a)f42.n152.z1.ieee.org) Please don't flame him, I'm trying to unbanish myself off the echo, not get him upset, however the thought of writing a program that sends a cookie to him every twenty minutes did occur, at least until I thought better of it.

2 1

random access into an encrypted file?
by zimm＠alumni.cco.caltech.edu 06 Jun '93

06 Jun '93

I'm enjoying the discussion of encrypting file systems, but have a perhaps-naive question: can the methods recently proposed here work for fast "random" access of bytes from the middle of a possibly-large file? Specifically, over the years I have written some free-text information-retrieval programs which build complete inverted indices to every word in a chosen text file (which may be many megabytes long, limited by disk space, not by RAM) --- and in order to fetch and display text quickly from an arbitrary point in the file, my programs do a lot of fseek() operations. If a file is encrypted under various schemes, I wonder how long it would take to fetch byte 100,000,000? Could it cause me some performance problems? :-) Just thought I'd raise the issue.... BTW, if anybody wants to work with large text files, the stuff I've done is all free under GNU GPL; for nicest user interface, see Mac version which hides behind HyperCard (in INFO-MAC archive at sumex-aim.stanford.edu, under directory info-mac/card with a name beginning "freetext", I think). Generic command-line C code to build indices is "qndxr.c" in various archives, and the generic command-line browser is "brwsr.c". See description in THE DIGITAL WORD, eds. Landow & Delany, MIT Press, 1993, pps. 53-68, for more details. Briefly, the programs let you scroll around in alphabetized word lists, generate key-word-in-context displays and do simple proximity filtering, and retrieve chunks of text on demand, very fast. Index-building is 15-20 MB/hour on an older Mac II-class machine, 60-80 MB/hour on a Sparcstation, etc. Best, ^z (no relation!)

3 2

My Poll.
by J. Michael Diehl 06 Jun '93

06 Jun '93

This is just a note to let you know that the deadline for my poll has been extended to Monday evening. My kitchen flooded yesterday and I will not have time to prepare the results of my poll till monday night. You may expect the results tuesday. Bummer. +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl(a)triton.unm.edu | But, I was mistaken. |available| | mike.diehl(a)fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+

1 0

Re: CryptoStacker
by Mark 06 Jun '93

06 Jun '93

>In the C programming library: > > CPHANT.ZIP C source for MSDOS network redirector > DRIVER.ZIP C/Asm source for generic driver skeleton > RDCF2.ZIP C source for complete MSDOS file system > >In the General library: > > CRAMDI.ZIP C source to RAM disk driver > FDCBIOS.ZIP Asm source to floppy disk driver How does someone no on compu$erve get access to these? archie didnt report anything. (Want to peek at the cphant.zip file) Mark mark(a)cheops.anu.edu.au

1 0

SPA Press Release
by mulivor＠crc.monroecc.edu 06 Jun '93

06 Jun '93

I recently received this press release from the Software Publishers Association. It gets better as it goes on. --Phil Mulivor mulivor(a)orion.crc.monroecc.edu -------------------------------------------------------------------- 06/04 1018 SPA RENEWS CALL FOR LIBERALIZING EXPORT CONTROLS WASHINGTON (JUNE 4) IDG PR SERVICE - At a National Institute of Standards and Technology (NIST) hearing Thursday on national cryptographic policies, the Software Publishers Association (SPA) explained how continued "munitions" export controls of mass market software with encryption capabilities were seriously harming the American software industry and renewed its call for significant export liberalization of mass market software using DES or other encryption algorithms such as RC2/RC4 at comparable strengths. SPA also warned that the Administration's recent announcement of its "Clipper Chip" initiative did not address the software industry's concerns and should not be an excuse to delay export liberalization. The SPA announced the preliminary results of its recent research which reveal a robust and rapidly expanding foreign market in encryption programs and products. "Unilateral US export controls do not make any sense given the widespread legal availability of foreign encryption programs," testified Ilene Rosenthal, SPA's general counsel. "Foreign companies will buy foreign encryption products if they cannot buy from American companies and in turn become ex-US customers. As a result, the U.S. Government will only succeed in crippling an American industry's exporting ability." The SPA research team preliminary concluded that: - The US no longer dominates the encryption field. In fact, the SPA has identified to date more foreign than domestic encryption programs and products (143 vs. 133). - There clearly are many foreign options for strong encryption, contrary to assertions by the U.S. government. SPA has preliminarily identified to date 80 foreign software, hardware, and combination hardware/software products for text, data, and file encryption from companies in 13 foreign countries. Forty-eight of these employ DES, which is nearly impossible to export from the U.S. in other than very rare circumstances. Sixty-three additional foreign encryption programs and products have been identified (including those from an additional five countries) but have yet to be investigated. However, SPA believes many of these also will be found to employ DES or other comparable strength encryption algorithms. - Fifteen foreign mass market encryption software programs and kits are available that employ the DES algorithm. These are published by companies in Germany, Israel, the United Kingdom, Denmark, Canada, Belgium, and Australia. These software programs are installed by the user inserting a diskette; the kits enable encryption capabilities to be easily programmed into a variety of applications. - Foreign companies increasingly recognize and are responding to the need to provide software only encryption solutions. Although the foreign encryption market is still heavily weighted towards encryption hardware and hardware/software combinations, the market trend is going to software. The SPA noted that in addition to these commercially available programs and products, any analysis of the availability of foreign encryption alternatives must consider programs available on the Internet, which is the largest global network connecting millions of users throughout the world. - DES is widely available on the Internet, including implementations that can be simply down-loaded and used. - A recently popularized encryption program entitled Pretty Good Privacy (PGP) also is widely available throughout the world. PGP implements the International Data Encryption Algorithm (IDEA), which provides protection comparable to DES. The program is intended for electronic mail, but also is ideal for encrypting files. It is available for free, may be used legally throughout Europe, whether in a business or at home, comes with easy-to-read instructions, is trivial to install, and simple to use. "Some government officials routinely assert that even if the Government prohibits America's software publishers from offering encryption features demanded by their customers abroad, we should not be concerned because there are foreign programs and products available," said Ken Wasch, SPA's executive director. "Our reseach shows that such an assertion is erroneous. In fact, there are a very large number of such programs and products available on the market today. The result is lost sales for American business without any improvement in national security." The Software Publishers Association is the principal trade association of the PC software industry. Its more than 1000 members represent the leading publishers in the business, consumer, and education markets. The SPA has offices in Washington and Paris, France. CONTACT: Software Publishers Association, Washington Terri Childs, 202/452-1600

1 0

Re: CryptoStacker, long term vision
by RYAN Alan Porter 06 Jun '93

06 Jun '93

On Thu, 3 Jun 1993, A1 ray arachelian wrote: > > 2) does anybody know how the hell Stacker or DoubleStor or > > whatever executes the actual interception of the read/write > > routines and stacks them? I don't get it at all. I am > > more than willing to learn to get this thing working though. > > > > Anyhow to make the story short, if I wrote an image mounter device driver which > would be able to grab DIM files and pretend that they were on the A: or B: drive > then we could also install the programs without breaking out the recylced disk > box. :-) Couldn't you just do that with the assign command in DOS? or is that a new command? > I never got around to it because of other projects, but, what you need to do is > to write a device driver that becomes accessible via the IOCTL calls. That's > the way logical drivers (such as Stacker) install themselves. Yeah, I am assuming that is the way I will have to organize the system. I want it to be totally transparant, that seems like a good way. > Also, the program you're writing (I believe) has been already written and is > part of Norton Utilities, but uses either DES or some other weak form of > encryption. You might want to buy Norton Utilities and play with that program > and see what makes it tick. Basically a program like MSD (Microsoft Diags) > can tell you exactly what interrupts it patches itself into. I have heard this from someone else. It kind of takes the wind out of my enthusiasm, but not too much... I still think that there is a need for a good, strong system out there with some seriously dedicated password key protection and such. Also, it needs to be freeware (or shareware, depending on how long it takes to write) so that security won't just be in the hands of the people who can afford to buy it from companies. I also think that it would be a lot more valuable if it were distributed with code so that any user who wanted could inspect it for trapdoors. > On to the sector remapping. The way stacker and doubledisk and the other > suite of driver level compressors work is basically, they allocate a huge > file on the hard drive, and then do a remapping at the sector level. That > is you've got the data itself and an index table into the data for every > sector. When a sector is written to the drive, the driver compresses the > sector, so say, it was 512 bytes, it now becomes 128 bytes (if we're lucky) > so what Stacker does is, looks in its index table, finds 128 bytes free in > the huge file it allocated, writes the data there, and then sticks the > position of the data, and it's size (after compression) in the index table. > (Of course it also marks that 128 bytes as taken.) Umm, perhaps this is overly optimistic, but I was hoping that I would be able to use an algorithm that did 1 byte in / 1 byte out encryption so that I wouldn't have to deal with sector remapping. This would greatly speed up the process, make it more crashproof, and besides, it would be a hell of a lot easier... I was thinking that I would even basically leave the FAT and such intact, or at least only slightly modified. > I believe it also does some other funky stuff like changes the allocation > table or the bytes free to twice the space it's got left, so that DOS > doesn't choke when it thought it had 10,000 sectors free and the hard > drive ran out of space when it tried to write #4,999. :-) > > So you might want to do this with RSA. But better yet, why don't you > find a quick compressor algorithm (say some sort of LZ type method) > and stick that in as well. This way you are writing a public domain > version of stacker >WITH< encryption. (Since you'd have to remap > the sectors anyhow, you might as well compress them too...) I have been pointed in the direction of the IDEA engine in PGP, which will take 1 byte in / 1 byte out. This would be ideal (snicker) for the reasons that I mentioned before. As for compressing also, that is a really good idea, but I think that I will leave that one up to posterity, or at least to the next guy that tries to midofy the thing, I am concerned enough with getting it to work at all, and compression would add the problem of having to do sector remapping, which I would like to avoid at first. > The above is just a theory and hasn't been tested. I believe that > this is what Stacker does, but I'm not exactly sure. :-) But it > does sound logically right. Sounds good to me, and it is consistent with the advice of others (thanks a lot guys, I really appreciate the help) and the books that I have found since this started two days ago... > So if I'm wrong, let me know as you've got my curiosity up in this > matter. I'll keep everyone updated no problem. How else am I going to get suggestions and help? -Ryan the Bit Wallah

4 3

Re: Dig. Cash Question.
by J. Michael Diehl 06 Jun '93

06 Jun '93

According to smb(a)research.att.com: > > If I understand this correctly, if p is not a prime, then n may not be > unique. > > Well, n isn't unique even if p is prime. Consider a=10,p=11. > 10^2=10^4=10^6=10^8=10^10=1 mod 11. You only get a maximum-length > cycle if ``a'' is a primitive root, hence the restriction I stated > in the part I deleted... That is, if a is a generator of G, or as close to one as possible. My thinking was obviously clowded... Not that I have a beer in me, I remember that for any element, a of group G, a will have order n, such that n|ord(G). This implies that there are n different (positive) powers of a which yield a particular number, b in our case. Each of which would qualify as a log. I think I understand. > It doesn't matter that n isn't unique, though you do want a good > distribution. Primitive roots have a maximal distribution, which is Then which root are we to use in discussion? +-----------------------+-----------------------------+---------+ | J. Michael Diehl ;-) | I thought I was wrong once. | PGP KEY | | mdiehl(a)triton.unm.edu | But, I was mistaken. |available| | mike.diehl(a)fido.org | | Ask Me! | | (505) 299-2282 +-----------------------------+---------+ | | +------"I'm just looking for the opportunity to be -------------+ | Politically Incorrect!" <Me> | +-----If codes are outlawed, only criminals wil have codes.-----+ +----Is Big Brother in your phone? If you don't know, ask me---+

1 0

NitV is DOWN!
by Stanton McCandlish 06 Jun '93

06 Jun '93

> DON'T call for PGP toys from my system any time this week, and likely next. > The system is DOWN, due to a motherboard video-related problem (among others). > Serves me right for buying mailorder, with a 1yr warranty (it's been 1 > year and 2 months. Of course.) NitV should be up and running and all > the crypto files available again within a couple weeks. Blagh. > Of course, what REALLY must've happened is the SS sneaked into my house in > the middle of the night and ran a magnet over my BIOS... >;) > > -- > When marriage is outlawed only outlaws will be inlaws! > Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS > Internet anton(a)hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 > Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA > Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) > Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:) > -- When marriage is outlawed only outlaws will be inlaws! Stanton McCandlish, SysOp: Noise in the Void DataCenter Library BBS Internet anton(a)hydra.unm.edu IndraNet: 369:1/1 FidoNet: 1:301/2 Snail: 1811-B Coal Pl. SE, Albuquerque, New Mexico 87108 USA Data phone: +1-505-246-8515 (24hr, 1200-14400 v32bis, N-8-1) Vox phone: +1-505-247-3402 (bps rate varies, depends on if you woke me up...:)

1 0

Software infrastructure
by mmidboe＠cs.uah.edu 06 Jun '93

06 Jun '93

CY>Buzzword alert. What is "TPU"? And who makes "Async Pro", and what CY>exactly does that do? Well, in the PC world, a TPU is just a Turbo Pascal Unit. It's become kind of a standard for making easy add-ons to programs since a lot of programmers use Turbo Pascal. Async Pro is written by Turbo Power software. Anyways, does anyone have any basic ideas on what functions would be really important for some kind of programmers toolkit? To narrow things down you might want to make a PGP toolkit that manipulates PGP keys and makes using PGP easier from other programs. So, does anyone have feedback on some good general PGP encrypted file manipulation functions? Once you make them easy to integrate into other programs I'm sure more and more people will pick it up. Reading through the vast amounts of C code on PGP is quite a daunting task.

1 0