September 2002 - cypherpunks-legacy

Re: CHAUM CHIMES IN
by cme＠ellisun.sw.stratus.com 18 Dec '03

18 Dec '03

>Date: 08 Sep 93 16:30:55 EDT >From: Sandy <72114.1712(a)CompuServe.COM> >Subject: CHAUM CHIMES IN >Message-Id: <930908203054_72114.1712_FHF95-2(a)CompuServe.COM> ..From: > SANDY SANDFORT Reply to: ssandfort(a)attmail.com [ . . . ] >Of course, the next letter to the editor calls for the adoption >of systems to track every vehicle at all times. The genius who >wrote the letter, thinks it would be a good way to prevent >nuclear, biological or chemical terrorism. Geeeeez. It was signed by Dorothy Denning, right? Actually, they should take that to its full conclusion. We need implants in every individual, broadcasting to the local surveillance agency, giving not only location but also every word spoken in the vicinity. It could also do a chemical analysis of the air in the neighborhood. It should also have a radiation counter. It should also monitor the host body, looking for signs of anger or sexual arousal? How else will we be guaranteed safe from mad bombers, rapists and child molesters? How else will our big budget LE agencies be able to protect us? I know. When it's finally adopted, worldwide, they'll call it the Ellison Plan. :-( - Carl

2 1

Stegno and DAT and digital music...
by Peter Wayner 18 Dec '03

18 Dec '03

In this week's Sunday NYT, Hans Fantel, their music guy, writes at length about the new "dithered" CD's and how the guys have improved the sound. He says that the original CD format was limited to 16 bits of sound because of costs. But many audiophiles reacted very negatively to the tinny, metalic quality to the music. For this reason, the companies have developed 20 bit DAT recording tape and then come up with ways to "dither" this into 16 bits. I am curious if anyone knows the details of these algorithms. Also, his point suggests that flipping the least significant bit of 16 bit music may not be imperceptable to some ears. If the classical music starts to sound tinny then there might be something subversive in the least significant bits. -Peter Wayner

2 1

Remail: errors
by HFinney＠shell.portal.com 18 Dec '03

18 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have been out of town for the last week, so I missed some CP mail. It looks like some good things are happening with remailers, though. Kudos to Karl, Sameer, and the others for their work! I have received many messages to my remailer in the last week which came from remail(a)tamsun.tamu.edu, which were PGP-encrypted apparently in an effort to get my remailer to send them. They did not work, though, because there was no "Encrypted: PGP" header to trigger the remailer's decryption. This can be arranged by creating the message something like this: ======================================================== :: Request-Remailing-To: hfinney(a)shell.portal.com :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- <rest of message> - -----END PGP MESSAGE------ ======================================================== This would then be sent to remail(a)tamsun.tamu.edu. I don't know whether the multiplicity of such erroneous messages is just due to one person stubbornly re-trying, or whether there is an error in one of the new programs for creating chained remailer messages. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLJaNuKgTA69YIUw3AQHrNwQAowMEQwuH6YyHoj6T7AqZFLNdTf+eqJ9L LhAatHS94nmC1smkfVNq0dZmigmkvBdMNEPlBZemmxALz+KJw6OSY/ULSBmuVNEq 5rJANh3XimoJWqLISy2lZiuC5Fw2R7UvRadcdM94pncSVvev92Fyf7CqEOOtrGAK PUzRds7BVNo= =FpLa -----END PGP SIGNATURE-----

2 1

more than spread spectrum
by cme＠ellisun.sw.stratus.com 18 Dec '03

18 Dec '03

There are alternatives to spread spectrum, if we're threatened with loss of freedom to communicate. We could lay our own wires/fibers. We could set up a mesh network of infrared lasers through the air. Last time I looked, there were no laws against shining lights out your window as long as they didn't bother anyone. An infrared laser could hardly bother anyone. We could produce a line of cheap cards to plug into a PC which would do packet routing, using a variety of physical links -- our own wires, lasers, very low range radio, .... Each card would connect to three or more neighbors and become part of the global mesh. Adaptive routing with no global map would suffice for the card and would keep the whole system peer-to-peer with no need for central control and no chance for central tapping. Of course all of these solutions require a high density of users. A college campus might be the right place to start. We could then branch out to cities. I suspect that a place like Chicago or NYC with high rise apartments might be the place to start -- many options for line-of-sight communications. The benefit isn't just for Cypherpunks. It's a free network for the masses -- like the original USENET (with each user donating routing and store/forward) but with unrestricted, low-range, continuously operating physical links. I'll volunteer to do the software for the node card. Does anyone have hardware design/fab to donate to the effort? - Carl

4 3

Real-world steganography
by pgut001＠cs.auckland.ac.nz 02 Oct '02

02 Oct '02

I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. According to the vendors, "HDCD has been used in the recording of more than 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and more than 175 GRAMMY nominations", so it's already fairly widely deployed. >From http://www.hdcd.com/partners/proaudio/overview.html: [...] Hidden Code Addition/Output Dither/Quantization The final step in the reduction to 16 bits is to add high-frequency weighted dither and round the signal to 16-bit precision. The dither increases in amplitude in the frequency range of 16 to 22.05 kHz, leaving the noise floor flat below 16 kHz where the critical bands of hearing associated with tonality occur. As part of the final quantization, a pseudo-random noise hidden code is inserted as needed into the least significant bit (LSB) of the audio data. The hidden code carries the decimation filter selection and Peak Extend and Low Level Range Extend parameters. Inserted only 2?5 percent of the time, the hidden code is completely inaudible-effectively producing full 16-bit undecoded playback resolution. The result is an industry-standard 44.1-kHz, 16-bit recording compatible with all CD replication equipment and consumer CD players. [...] The paper describing the process is available under the somewhat misleading name http://www.hdcd.com/partners/proaudio/AES_Paper.pdf. The description of the stego en/decoding process is on p.15 (it's a rather long excerpt, but it's interesting stuff): As part of the final quantization, a hidden code side channel is inserted into the LSB when it is necessary for the encoder to inform the decoder of any change in the encoding algorithm. It takes the form of a pseudo-random noise encoded bit stream which occupies the least significant bit temporarily, leaving the full 16 bits for the program material most of the time. Normally, the LSB is used for the command function less than five percent of the time, typically only one to two percent for most music. Because the hidden code is present for a small fraction of the time and because it is used as dither for the remaining 15 bits when it is inserted, it is inaudible. This was confirmed experimentally with insertion at several times the normal fraction of time. [...] The mechanism which allows insertion of commands only when needed consists of encapsulating the command word and parameter data in a "packet". A synchronizing pattern is prepended to the data and a checksum is appended. The resulting packet is then scrambled using a feedback shift register with a maximal length sequence and inserted serially, one bit per sample, into the LSB of the audio data. The decoder sends the LSB's of the audio data to a complementary shift register to unscramble the command data. A pattern matching circuit looks for the synchronizing pattern in the output of the descrambler, and when it finds it, it attempts to recover a command. If the command has a legal format and the checksum matches, it is registered as a valid packet for that channel. The arrival of a valid packet for a channel resets a code detect timer for that channel. If both channels have active timers, then code is deemed to be present and the filter select data is considered valid immediately. However, any command data which would effect the level of the signal must match between the two channels in order to take effect. The primary reason for this is to handle the case where an error on one channel destroys the code. In such a case, the decoder will mistrack for a short time until the next command comes along, which is much less audible than a change in gain on only one channel, causing a shift in balance and lateral image movement. If either of the code detect timers times out, then code is deemed not to be present, and all commands are canceled, returning the decode system to its default state. If the conditions on the encoder side are not changing, then command packets are inserted on a regular basis to keep the code detect timers in the decoder active and to update the decoder if one starts playing a selection in the middle of a continuous recording. Since the decoder is constantly scanning the output of the de-scrambler shift register for valid command packets even when none are present, the possibility exists that there may be a false trigger. For audio generated by the encoder, this possibility is eliminated in the absence of storage and transmission errors by having the encoder scan the LSB of the audio data looking for a match. If a match to the synchronizing pattern is found, the encoder inverts one LSB to destroy it. Modern digital storage and transmission media incorporate fairly sophisticated error detection and correction systems. Therefore, we felt that only moderate precautions were necessary in this system. The most likely result of an error in the signal is a missed command, which can result in a temporary mis- tracking of the decoding, as mentioned above. Given the low density of command data, and the small changes to the signal which the process uses, these errors are seldom more audible than the error would be in the absence of the process. The chances of a storage error being falsely interpreted as a command are extremely small. For material not recorded using the encoder, a small probability for a false trigger does exist. Given a moderate length for the scrambling shift register so that its mapping behaves in a noise-like fashion and a choice of synchronizing pattern which avoids patterns likely to appear in audio data with a higher than average probability, susceptibility to false triggers can be made arbitrarily small by increasing the length of the part of the packet requiring a match. In the case of the current system, the combination of the synchronizing pattern with the bit equivalence for all valid commands plus check sum results in a required match equivalent to 39 sequential bits. For a stereo signal, in which a match must occur in both channels within a one second interval and the commands in both channels must specify the same gains, this amounts to an expectation of one event in approximately 150 million years of audio. The scrambling operation uses a feedback shift register designed for a maximal length sequence in which data taken from taps in the register are added using modulo two arithmetic, equivalent to an 'exclusive or' operation, and fed back to the input of the register. For a given register length there are certain configurations of taps which will produce a sequence of one and zero values at the output that does not repeat until 2N-1 values have emerged, where N is the length of the shift register. This corresponds to the number of possible states of the shift register minus one illegal state, and is called a maximal length sequence. Such an output sequence has very noise-like properties and, in fact, is the basis of some noise generators. We use the noise-like behavior of the generator to scramble the command signals by adding them modulo two to the input of the shift register, as for example in Figure 7a. This has the advantage that a second similar shift register with taps in the same places but with only feed forward addition modulo two (Figure 7b) will reproduce the original input sequence when fed with the output of the first one. The fact that the decode side has no feedback means that the initialization requirements are limited to having N input samples prior to the beginning of decoding, which means that the decoder will "lock up" very quickly. In this scheme, the presence of a bit error anywhere in the length of a packet plus initialization sequence will completely scramble the data, preventing recovery. However, in practice, this has not been a problem for reasons described above. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

8 8

Re: smartcards
by Steve Thompson 01 Oct '02

01 Oct '02

Quoting Trei, Peter (ptrei(a)rsasecurity.com) > The phone SW world is nowhere near as closed as you think. > > * Thousands of developers are writing Java applets for Japanese iMode > phones. > * Hundreds are developing applets for the Blackberry 5810 and 5820 phones > (free Java-based IDS from RIM). > * Similarly, the high end Pocket PC and Palm phones both have free or > inexpensive > development environments (C/C++) > * Finally, Qualcomm phones support BREW (free SDK, expensive training). I stand corrected. I'm even reading a short bit about Nokia's new 3g phone: http://www.theregister.co.uk/content/54/27310.html "The device, known as the Nokia 6650, is also notable for allowing users to record up to 20 seconds of video (128x96 pixels) with sound using a built in VGA camera employing 4096 colours, the first Nokia phone to offer the facility...." "Other features include a multimedia messaging service (MMS) client, a WAP 1.2.1-compatible browser, integrated Bluetooth, a "wallet" application for mobile transactions, and a Java 2 Micro Edition (J2ME) virtual machine based on the mobile information device profile (MIDP)." Includes infrared and USB as well. Not much quickly available describing the wallet app, but it probably isn't peer-to-peer. > My take on the situation is that the platform vendors are so anxious to get > developer mindshare, and new apps, that they are for the most part giving > away the development environments and specs. IOW, a decent number of platforms are ready to go. Cool. Regards, Steve

1 0

Howdy
by xxxDerrickxxx＠hotmail.com 01 Oct '02

01 Oct '02

Want to make a million bucks this year? Make a million!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ME TOO BUT IT'S probably NOT GOING TO HAPPEN!!!!! However if your looking for the opportunity to make a couple thousand a week, working form home, with your pc, we need to talk. If you're over 18 and a US resident, Just Click REPLY Send me your Name, State, Complete telephone number, and the best time to contact you.

1 0

RE: smartcards
by Trei, Peter 01 Oct '02

01 Oct '02

> Steve Thompson[SMTP:stevet010@yahoo.com] wrote: > > I'm surprised that nobody has mentioned cell-phones as a digital cash > platform. > Perhaps this belabours the obvious, but I'll spell it out anyways: > > o They are ubiquitous. > > o Most of them have an IR port and many contain enough storage and > horsepower to keep and play small MP3 collections. Chaumian digital > cash > code should fit easily. Hell, some companies are already making > noises > about full-motion video. How long before the damn things have a > digital > camera built in? > > o Peer-to-peer transactions will obviously work via IR. Central > clearing > mechanisms will work through the phone net. Thus they embody the > basic > infrastructure for both worlds. The entire thing could be done over > SMS, > of course, but IR for peer-to-peer, day-to-day transactions is best > from a > privacy and usability standpoint. > > o PC-based software is in use for the synchronisation of calendar data, > etc. > Many people are already familiar with using their phones for these > kinds > of purposes so what's one more application to the user? > > The problem is that phone software is (to my knowledge) all closed-source > and > running on proprietary hardware. What's the liklihood of manufacturers > opening up their phones for third-party code? A Java VM might do it, as > might > something lean like an Inferno VM. More informed list members could > probably > suggest other virtual machines which would suit our purposes. > [...] > Regards, > Steve > The phone SW world is nowhere near as closed as you think. * Thousands of developers are writing Java applets for Japanese iMode phones. * Hundreds are developing applets for the Blackberry 5810 and 5820 phones (free Java-based IDS from RIM). * Similarly, the high end Pocket PC and Palm phones both have free or inexpensive development environments (C/C++) * Finally, Qualcomm phones support BREW (free SDK, expensive training). My take on the situation is that the platform vendors are so anxious to get developer mindshare, and new apps, that they are for the most part giving away the development environments and specs. Peter Trei

1 0

Re: smartcards
by James A. Donald 01 Oct '02

01 Oct '02

-- On 30 Jan 2050 at 32:210, Steve Thompson wrote: > I'm surprised that nobody has mentioned cell-phones as a > digital cash platform.[....] > > The problem is that phone software is (to my knowledge) all > closed-source and running on proprietary hardware. What's > the liklihood of manufacturers opening up their phones for > third-party code? An open platform would be a combined cell phone and palm top computer. Lots of people are trying to move this -- so far without wide acceptance. Paypal's original vision was that people would use palm pilots with IR. If phones developed palm pilot capabilities, this vision would become more useful. I think combining the palm pilot with the cell phone is more feasible once we develop a good voice controlled computer, after the fashion of startrek, which may be some time off. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG z0mctqiLain3vlXnFZTOy5PEVJIwCeg0x7zxl4RQ 4DWhd8THkIxyeHtI7sSA5O1d9IKi7WwGZVh6roOOb

1 0

Hepsi xrds
by M Deki 30 Sep '02

30 Sep '02

Ensest siteler - En son videolar - Yüksek kalite resimler Sýnýrsýz porno arþivi yenilendi: Onlarca film ve fotoðraf Normal internet baðlantýnýzdan 10 kat hýzlý bir baðlantýyla, videolarý kendi bilgisayarýnýzdan izlediðiniz gibi izlemek veya aklýnýza gelebilecek her kategoride binlerce yüksek kaliteli resim e ulaþmak için http://www.jetseks.com adresini ziyaret ediniz. Sitemiz tüm isteklerinizi karþýlayacak kadar geniþtir. Sadece hayal edin ve izlemeye baþlayýn. Ýyi eðlenceler http://www.jetseks.com

1 0