December 2003 - cypherpunks-legacy

Re: CERT advisory
by smb＠research.att.com 17 Dec '03

17 Dec '03

>The big issue, in my mind, is how the ftpd is going to get the key >to unlock the *system's* private key... Do you compile it into the >code? Should ftpd ask for it when it comes up? Since active interception is not nearly so easy as passive listening, it would be appropriate to use a Diffie-Hellman key exchange in this situation. This protocol has no persistent private keys, so the issue of keeping a private key around securely is not an issue. But you still have to type a password to a command that itself could have been compromised. (Not that D-H wouldn't be a tremendous help, of course.) All of the hand-held authenticators I'm familiar with require that the host -- or a dedicated, trusted, security server -- keep a secret key per user. That's not a great idea. Bellcore's S/Key doesn't, but I don't know of any hardware devices that implement it. Another possibility would be hand-held digital signature boxes that could sign a random challenge from the host.

1 0

Re: Magic Money Digicash System
by fb＠cyberg.win.net 17 Dec '03

17 Dec '03

> Magic Money is a digital cash system designed for use over > electronic mail. The system is online and untraceable. Online > means that each transaction involves an exchange with a server, > to prevent double-spending. Untraceable means that it is > impossible for anyone to trace transactions, or to match a > withdrawal with a deposit, or to match two coins in any way. This is the neatest thing I have read in a long time. Where can I get one? > The client module then generates proto-coins, which are > blinded but unsigned. It produces an output file containing > Alice's coins, and the new proto-coins. > Bob mails this to the server. The server counts up Alice's > coins, checks their signatures, and checks for > double-spending. It puts the coins on the cancelled list, > signs the proto-coins, and mails them back to Bob. Bob runs > his client module on the reply message. It unblinds the > signed coins and adds them to his coin file. This completes > the transfer. 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. How does the bank deal with collisions in the 16 byte values of coins? 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. 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. 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. --------------------------------------------------------------- Francis Barrett, F.R.C. | Thou canst not travel on the path | The Cybernetics Guild | before thou hast become the Path | fb(a)cyberg.win.net | itself. | ---------------------------------------------------------------

1 0

No Subject
by smb＠research.att.com 17 Dec '03

17 Dec '03

Subject: clipper_q-and-a.txt >Q. Who will hold the escrowed keys? >. The government. All this bullshit doesnot state that a court order is required, rather 'legal authorization', which means the NSA for foreign intellingence purposes without a court order. Perhaps what is needed is statuatory protection to prevent the NSA from eavesdropping on U.S. Citizens, communicating domestically, without a court order. The law already says that. The government's right to spy on non-Americans is spelled out in the Foreign Intelligence Surveillance Act, 50 USC 1801. Enforcing it is another matter, of course. I saw an AP wire story today that's illuminating. It seems that for years, members of the Tennessee Highway Patrol have been subpoenaing phone company records without proper authority. They've been using a rubber stamp with the commissioner's signature, apparently without his knowledge or consent -- which he probably wouldn't have given, since under Tennessee law the Highway Patrol can deal with crimes committed on a highway, car theft, odometer tampering, or (of course) drug dealing. The only state police agency that has such subpoena authority is the Tennessee Bureau of Investigation -- and even they're limited; the D.A. is supposed to do such things after authorization by the grand jury. And the phone company -- they complied, of course; they had no idea (they said) that the subpoenas were illegal.

1 0

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