December 2003 - cypherpunks-legacy

KERT Advisory
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

From: KERT Advisory <kert-advisory-request(a)kremvax.su> Date: Fri, 4 Feb 94 21:14:40 EST To: kert-advisory(a)kremvax.su Subject: KERT Advisory - Ongoing Network Monitoring Attacks Organization: Komputer Emergency Response Team : 714-731-0699 ============================================================================= KA-94:01 KERT Advisory February 4, 1994 Ongoing Network Monitoring Attacks ----------------------------------------------------------------------------- In the past week, KERT has observed a dramatic increase in reports of intruders wishing to monitor network traffic. Systems of some service providers have been compromised, and all systems that offer remote access through normal channels are at risk. The intruders have already captured information from tens of thousands of users outside the political boundaries of the United States. The current attacks involve a network monitoring tool that uses the promiscuous mode of a specific network interface, the telephone, to capture host and user identities and data on newly established telephone sessions. In the short-term, CERT recommends that all users at all sites that offer remote access resist attempts by any persons or organizations to install Trojan-horse devices which purport to "enhance" privacy but in fact are designed to provide unauthorized access to sensitive information. While the current attack is specific to /dev/Clipper, the short-term workaround does not constitute a solution. The best long-term solution currently available for this attack is to reduce or eliminate the transmission of user data in clear-text over the network, and to reduce or eliminate the access of the intruders to the network interface design and specification process. -----------------------------------------------------------------------------

1 0

STEG: a real-life use for steganography
by hughes＠ah.com 17 Dec '03

17 Dec '03

I had an extremely interesting conversation with a fellow last night, say, X. A mutual friend of ours had steered him towards me. X has contacts in a country C which will remain nameless. The government of C is extremely repressive and has a large internal police force. The situation, evidently, is one similar to the old USSR, where masks behind masks were used in daily life, little is exactly as it appears, and the default discourse is sideways speaking. The scenario is almost worst-case. There is a need for steganography, since the use of cryptography is grounds for suppression; likewise there is a need for covert channels. There is a need for double-blinding of identities, since one's friends may be difficult to detect. And so on. The aspect that _is_ good is that C is not the whole world, and there are plenty of us not in C. The first most useful facility to set up, X thinks, is simply news from outside of C as a bypass of the media in C--wire service articles about C, for example, as well as a feed of the newsgroup "soc.culture.<C>". Here's the technique we came up with last night. C has an indigenous music M which is periodically performed in the United States. We were thinking about pressing short-run CD's of these live performances. We all know where the news feeds go. The CD's would be distributed via standard music channels and would be surprisingly brisk sellers. The costs of the project can evidently be footed by willing members of the M industry in C. Now let me address the standard comment "Oh, steganography completely solves that problem." Please. That's like saying, "Oh, just use an internal combustion engine to solve your long distance transport problems." Such statements are a failure of imagination and seriousness. A practical system to carry this project out is quite large. I see at least the following pieces needed: -- A facility to gather the data being put on the disks. This by itself is no trivial task, since it involves the collection of many disparate sources. -- An authoring system to arrange the data, once collected, into a usable structure. -- An encryption system for the arranged data. Such a system can't treat the data as one long stream, because of the segmented nature of the data. The ability to mount the CD as a file system would be good leverage for other programmers. -- A mastering system to combine a music master CD (done separately) and a data master (in some format) into a new music master CD. This will, at the least require a machine with a CD reader and writer. Blank media, FYI, for a CD writer are about $20/disk. The CD writer is about $5K. These numbers are approximate and falling rapidly. -- A CD pressing facility. These are commercially available at quite reasonable cost in quantities in the 100's. -- A CD distribution system. This will likely be the M industry, and thankfully the details of international shipping and customs will be taken care of, as well as retail distribution. -- A decryption system to get the data off the CD. -- Client software to make use of the information. It need not all be in text format. -- A key distribution system. A secret key per CD and word of mouth may be sufficient. A system to make rememberable sentences out of an arbitrary 128 bits (and the inverse) would be useful to facilitate word of mouth. This is no small task. Those interested in participating may start working on any of the above. The tasks are fairly separable. Here are some that I can identify as critical. -- A standard for encoding data into the low bits of an audio CD. This will likely require a lot of specific knowledge of the low level encoding and error correction systems used in CD's. I do know that they are not simple, being much more than bit-correcting linear codes. -- A standard for the encoding of file system data onto these low bits. This should be a separate document, even though the design of this will be influenced by the bit encoding standard. Some adaptation of existing file system standards may be appropriate. -- A standard for the encryption format for the file system. It may be that Matt Blaze's CFS cryptograpy can be lifted wholesale. -- Multiplatform software support for all of the above. I am pleased to have a real example to work on, rather than a lot of wixering about hypotheticals. I welcome discussion of this topic. Eric

5 4

IMPORTANT: unsubscription
by hughes＠ah.com 17 Dec '03

17 Dec '03

This is the mail I send to everyone who tries to unsubscribe by sending to the list. After I send this message, I delete it from my inbox and take no further action to that piece of mail. Read it. Eric ----------------------------------------------------------------------------- The cypherpunks list is for discussions on implementing cryptography. To mail to the whole list, send mail to cypherpunks(a)toad.com Every mail message sent to this address will be forwarded to everyone on the list. Make sure that the message you wish to send is appropriate for such a broad delivery. If you want to be added or removed from the cypherpunks list, or have any other questions which pertain to list management, send mail to cypherpunks-request(a)toad.com I don't manage the list from my regular account, so such mail which ends up in my ah.com account will just get you another copy of this file. Eric Hughes maintainer of the lists cypherpunks(a)toad.com and cypherpunks-announce(a)toad.com

1 0

Hughes' "real-life use for steganography"
by Seth Morris 17 Dec '03

17 Dec '03

[Eric Hughes described a situation where data smuggling is required, and asks for discussion on practicle and practicable mechanisms (with appropriate and far too rare here emphasis on practicable). This is the sort of real-worldish issue I've been on this list for, so, despite my opinion that this doesn't sound like a real case, I'd like to add my thoughts.] What is needed here is not encryption, by steg, of course. Why worry about key distribution at all? If the data is being sent in bulk, it will find itself into the hands of the local Big Bro, and the transport medium will be exposed and (presumable) confiscated. This will get the M industry into trouble, and lose the transport medium. This seems more like a case for point-to-point transport to several distribution sites withis the country, where more anonymous transport must be arranged. At the very least, no industry should be placed at risk without the means to protect itself. Maybe DAT tapes of "bootleg" recordings of music M? Like Grateful Dead tapes, only edited to contain the data. This way, only certain tapes have data, and the tapes can find their way into the hands of those who can decode and distribute. Is there, within the country, a suitable transport medium that is transient and frequent? Someone suggested weather maps (sorry I forgot someone's name) but these don't seem perfect. What about scanned in art GIFs on a ntionally available network? Hmmm....... Compuserve? The problem I have with using steg as the mass-transport (other than loss of transport medium once it is discovered and loss of a cultural industry) is that it only reaches those with CD-ROMs. This is generally a small percentage of people. Some in-country transport to the technologically uneducated is necessary. This may be out of the scope of this discussion. For the initial transport, why be cross-platform? If MS-DOS machines with CD-ROM or DAT readers are acailable (or PIC's can be brought in... hmmm... anyone know how to encode a Photo-CD? "Tourist shots... Grand Canyon, Yosemite Nat'l Prak..."), there is some program on comp.binaries.ibm.pc that can encode some .com files as readable text (Not uuencode, the text IS the .com file). A simple de-stegger could be sent in this way written on a sheet of paper. Something similar could be worked out for other platforms (maybe not this simle, though). They key problem I see is regular, bulk transport of data to be distributed to a mass of people at random containing cantraband information is unlikely to sustain an information revolution. Distribution of the data to a few people who can make use of it while remaining anonymous seems more effective. Better still would be to find some way that anyone could receive ALL the information easily and untraceably, which is what I think the CD scheme was aimed at. Unfortunately, it is risky and only gets data to the privedledged few. Sorry if this rambled, I'm doing this off the top of my head and with a fever. Seth Morris (Seth.Morris(a)LaUNChpad.unc.edu)

1 0

Re: Running regularly
by mbriceno＠netcom.com 17 Dec '03

17 Dec '03

I wrote: >> The next problem that must be addressed is the auto-logout upon >14min of >> inactivity on the modem level that Netcom imposes on you. There is a simple >> 2 line command that you can add to your .login file to disable the >> auto-logout. I saw it once posted in one of the Netcom newsgroups, but I >> lost it. Perhaps you might post the question there. I would not advise to Ed Carp wrote: >Did you ever get an answer to this one??? I know that TMOUT in bash controls >the shell timeout - does this have an effect?? I don't know if TMOUT has anything to do with it. I posted the queston in the appropriate Netcom newsgroups and hope that the original poster will see it and send me his script. Once he does I will post it to the list. After all,there is no reason why one shouldn't be able to use one's computer for other purposes while Netcom's machine is factoring that 50 digit number ;-) -- Marc Briceno <mbriceno(a)netcom.com> PGP public key by finger

1 0

Stego for Video ?
by Matthew Bernardini 17 Dec '03

17 Dec '03

Have any programs been written that would allow for three dimensional stego in moving pictures ? I think this would make it a little more difficult to detect. How about more advanced graphical techniques like using a stego file as a map in a renderer ? The person who received the picture would know for instance that all the vertical walls, or all the brick surfaces, etc were stego encrypted messages. It would take some sophistication to reverse engineer the rendered picture, but necessity is the mother of invention. The actual image would not contain any specific information, but would be a disguised "envelope" for other pictures within the picture. Matt ----------------------------------------------------------------------------- | Rutgers University Computing Services Matthew Bernardini | Hill Micro/Graphics Center 7804 McCormick | Site-Manager (908) 878-0946 | 017 Hill Center | (908) 932-3129 (908) 932-4921 -----------------------------------------------------------------------------

1 0

ViaCrypt Encryption Hardware
by Mike Ingle 17 Dec '03

17 Dec '03

Some interesting flyers for ViaCrypt hardware encryption devices: There are three of them. The DigiSig+ D350 is an external device which hooks up to a parallel port. The D355 is similar but hooks up to a serial port. Both of these are flat boxes that look like external modems. The D360 is an internal board, and the D150 is a software emulator. All of them do the same things: RSA, DES, and DSS. The hardware devices have tamper-resistant memory to store secret keys, which can be generated internally. ViaCrypt says the hardware boxes will support PGP soon. All of the devices are controlled by a script language. The hardware units take ISO Memory Cards. ViaCrypt PGP is also selling for $99. ViaCrypt's number is 1-800-536-2664 or 602-944-0773 --- Mike For the person who requested my PGP key: Type bits/keyID Date User ID pub 1024/569A09 1993/07/31 Mike Ingle <mikeingle(a)delphi.com> sig 87C0C7 Edgar W. Swank <edgar(a)spectrx.saigon.com> sig 9C0865 W.Meredith <Genie w.meredith(a)genic.geis.com> Key fingerprint = AB B7 D7 70 4D 32 72 64 79 63 7F 05 07 1D 62 5D -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAixa6xEAAAEEAN0a4+5zXcAbvGCkhWMowzko1fjc+9Q/kWsPXPABJ1H12wmZ fvsTOlIZKsYVG9oulz6N928btkP+CBWAKEyykDSaD3/HQBpg5T3/T6CVQCCkfGJx qvdJa6OdY0f7d83o2MX2P58veYqgXuiDSL0BUtqXcF1GNeV+ra2f+EADVpoJAAUR tCFNaWtlIEluZ2xlIDxtaWtlaW5nbGVAZGVscGhpLmNvbT6JAJUCBRAtTrsZ3ic1 /dqHwMcBAYXmBACRfSLCOBa3VfIMf4IhwqqxBToNqzJuD1g9N97A6SJ7/7E4/ux+ gulv3EsQJl2SXA6tnKPaZVPdDEOwW0+I+/YyT4YkeXiu7y7bgQSjeGdiElJaMboO vNcdNUaDWBn0t3+h1B9UGE29/CyHXPGVzkh8W+mK1J+3GrrCxoIZch9RTIkAlQIF EC0hm4Q+dhgw+ZwIZQEBXxcEAKw8CGgLbYjmPPeFSvc9KGnPn10ky8ltuFwRg5zu tLN70WpkQtivHA74d4CTYroklOj//HiBlVAb04Pl31Ypug6F3PUiEZC4thlJ4BeF 3q4LJSHvD70gYZ3uzwEn/ZOqfAn79ehsVpsiCfh6haZN0oJfJpz7Tr5c1eVAyl99 ZAdb =/VCZ -----END PGP PUBLIC KEY BLOCK-----

1 0

Looking for lost mail
by Mike Ingle 17 Dec '03

17 Dec '03

I lost some list mail today. Could someone please forward me the missing messages? These are the last ones I got. Everything between this and the "KERT Advisory" joke is what I lost. Thanks, Mike Some people have been asking how to run background tasks on Netcom. How about this: have your task run, then send a ping to a remailer. When the ping comes back, your .forward file will start the task back up and it can run, then ping the remailer again. From: IN%"mech(a)eff.org" "Stanton McCandlish" 4-FEB-1994 20:44:29.91 To: IN%"eff-board(a)eff.org" CC: IN%"eff-staff(a)eff.org", IN%"comp-org-eff-talk(a)cs.utexas.edu", [ everywhere ] Subj: White House crypto briefings: Clipper, FIPS, escrow agents, export From: IN%"smb(a)research.att.com" 4-FEB-1994 21:03:12.11 To: IN%"hughes(a)ah.com" CC: IN%"cypherpunks(a)toad.com" Subj: RE: CERT advisory From: IN%"fb(a)cyberg.win.net" 4-FEB-1994 21:08:15.44 To: IN%"cypherpunks(a)toad.com" Subj: RE: Magic Money Digicash System

1 0

Re: Magic Money Digicash System
by Hal 17 Dec '03

17 Dec '03

From: fb(a)cyberg.win.net (Francis Barrett) > > Magic Money is a digital cash system designed for use over > > electronic mail. > This is the neatest thing I have read in a long time. Where can I get > one? FTP to csn.org, cd to /mpj, read the file README.MPJ which will tell you a directory to switch to, do that, cd to pgp-tools (or pgp_tools, or pgptools, I forget which), and get magicmny.zip. Then unzip and build it. > A few questions. Since the client which generates the proto-coins is > under the control of the consumer, the bank has no way of making sure > that he is not running his own code, or that the RNG he is using is > cryptographically strong, or even that he is not distributing modified > client programs to other users. None of these things should cause major problems. At worst useless coins would be generated. Initially, users might send their coins in right away to confirm that they are OK until they get some confidence in the program. > How does the bank deal with collisions in the 16 byte values of coins? This will practially never happen if they are chosen randomly. Bad randomness could produce coins which match ones which have already been spent (if somehow your RNG got into exactly the same state as someone else's), so they would be valueless. I think the program makes you initialize a random file before using it, so just make sure you put something random there! > What if the user picks the numeric values for the server to sign in a > way which leaks information about the banks private key? RSA is much > more secure when signing random-esque data, like a message digest, > than it is when signing numbers provided to it by some outside party. I don't think there are any values you can sign which would give away a private key. Even signing "1" or "2" should be safe, I think, since the secret key is the size of the modulus. I ftp'd a paper recently mentioned on imp-interest (on "anonymous credit cards") which claimed that new cash could be generated from sets of old cash in Chaum's scheme. I don't believe this, and the ref was to a paper "in preparation" by the authors. I'll try sending them email to ask about this. > Similarly, how can the consumer trust the bank's representation that > money has already been spent? Surely the bank should be required to > publish a list of cancelled coins and timestamps with a running MD5 > hash periodically for inspection by the unwashed masses. Here is how this problem would arise. Alice has some cash, which she sends to Bob to buy something. Bob sends it to the bank to be verified and turned into fresh cash before he will send the goods to Alice. But the bank says the cash has been spent before, and Bob reports this to Alice. Alice insists that she has never spent this cash before. Now, this is like a mystery story. Who is telling the truth? Maybe Alice is lying. Maybe the bank is lying. Maybe they are both telling the truth and someone broke in and stole Alice's cash while she was sleeping, copying it from her computer and spending it before she could. Ignoring that last possibility for a minute, it is basically Alice's word against the bank's. In general, in situations like this, we often go by the reputation of the parties involved. If the bank really is cheating, there will be lots of other people like Alice, people with good reputations, who are making similar charges. This will make people stop trusting the bank. On the other hand, if Alice is cheating, this is probably not the first time. In time she will get a reputation for being untrustworthy. The idea of publishing lists of used coins is interesting but I'm not sure it helps. Double-spending could easily occur close together in time, between publication of lists. A cheating bank could claim a coin had been spent just before the actual coin came in. > What do you do about lost messages from the server to the client. > Once coins have been recorded as spent, they cannot be redeemed again. > Yet the mail message containing the new coins may have been lost in > transit. The server should re-transmit the message if it does not arive. We discussed this a while back and it appears safe for everyone in these protocols to re-transmit messages freely if the other person claims never to have gotten them. Even if they are lying, what is the harm - you are just sending them information they already have. Good questions. Hal

1 0

SQUISH II, the SEQUEL
by L. Detweiler 17 Dec '03

17 Dec '03

Hello, my mailbox has been awfully quiet lately from cypherpunk rants, and I need a bit of a massage at the moment, so I wanted to ask you a question. Have you considered what I was saying about preventing `abuse' of remailers? I have given you some time to formulate a plan. so-- could someone email me your new official Cypherpunk ethical guidelines for anonymous posting, involving your opinions and procedures on libel, harassment, and `violent death threats'? what's that? you don't have an official policy or any safeguards? I guess that means that `anything goes' (quite literally!) kind of a disturbing policy, because someone simultaneously very ingenious and malicious could create some major annoyances. I guess you already know that. but even the past `operations' could pale in comparison to future ones. the possibilities are really limitless. imagine what can be accomplished when no one is held accountable for what they post! why, it is a recipe for Utopia. cypherpunks, I so admire your vision of the future. BTW, I want to commend you anonymous site operators for your resilience. it does appear that the remailers are fairly secure, at least, that is the picture portrayed to `outsiders'. of course, with insiders, it is a different story. but in a certain interesting application of anonymous remailers, e.g. an enemy attacking the remailers themselves, the confidentiality of identity among `insiders' is not critical. in fact, it can be very satisfying for an enemy to strike his foe, even while the foe sees his face, but can do nothing about it because of his own predicament. even more delightful (for the attacker, that is!) is the situation where the `predicament' is not even due to the attacker, but entirely the enemy himself. in other words, the most effective and devastating tactic of guerilla warfare is to twist technology to get your enemy to shoot *himself*.

1 0